Slow performance on job_info method

[mojolicious]

Slow performance on job_info method

[kraih]

Sounds like a good idea.

[kraih]

Afraid i can't replicate your results though.

 Index Scan using minion_jobs_pkey on minion_jobs j  (cost=0.42..7523.09 rows=1 width=111) (actual time=39.652..39.653 rows=1 loops=1)
   Index Cond: (id = 100000)
   SubPlan 1
     ->  Seq Scan on minion_jobs  (cost=0.00..7514.64 rows=9923 width=8) (actual time=39.619..39.619 rows=0 loops=1)
           Filter: (j.id = ANY (parents))
           Rows Removed by Filter: 200000
 Planning time: 0.134 ms
 Execution time: 39.690 ms
(8 rows)

Even after creating the index and running this query many times, PostgreSQL insists on using a seq scan.

[avkhozov]

Sadly. Most likely I've been experimenting with set enable_seqscan to off; that gave this result. Don't know why postgres query planner don't use this index by default.

[kraih]

I might have found a solution that works most of the time. Will not release it to CPAN for now though, so we can test it some more. a42fae8