Talk About Network

Google


Register and Login
Nick
Password
Register create new account Sign up is FREE and you can post replies, new topics, bookmark posts and more!
Recover lost password


Data Bases > Pgsql Performance > Re: Message que...
Latest [ Topics | Posts ] Archive Post A New Topic Post a Reply
<< Topic < Post Post 5 of 5 Topic 4004 of 4352
Post > Topic >>

Re: Message queue table..

by Chris Browne <cbbrowne@[EMAIL PROTECTED] > Apr 18, 2008 at 03:57 PM

jesper@[EMAIL PROTECTED]
 (Jesper Krogh) writes:
> I have this "message queue" table.. currently with 8m+
> records. Picking the top priority messages seem to take quite
> long.. it is just a matter of searching the index.. (just as explain
> analyze tells me it does).
>
> Can anyone digest further optimizations out of this output? (All
> records have funcid=4)
>
> # explain analyze SELECT job.jobid, job.funcid, job.arg, job.uniqkey,
> job.insert_time, job.run_after, job.grabbed_until, job.priority,
> job.coalesce FROM workqueue.job  WHERE (job.funcid = 4) AND
> (job.run_after <= 1208442668) AND (job.grabbed_until <= 1208442668)
> AND (job.coalesce = 'Efam') ORDER BY funcid, priority ASC LIMIT 1
> ;

There might be value in having one or more extra indices...

Here are *plausible* candidates:

1.  If "funcid = 4" is highly significant (e.g. - you are always
running this query, and funcid often <> 4), then you might add a
functional index such as:

  create index job_funcid_run_after on workqueue.job (run_after) where
funcid = 4;
  create index job_funcid_grabbeduntil on workqueue.job (grabbed_until)
where funcid = 4;

2.  Straight indices like the following:

   create index job_run_after on workqueue.job(run_after);
   create index job_grabbed_until on workqueue.job(grabbed_until);
   create index job_funcid on workqueue.job(funcid);
   create index job_coalesce on workqueue.job(coalesce);

Note that it is _possible_ (though by no means guaranteed) that all
three might prove useful, if you're running 8.1+ where PostgreSQL
sup****ts bitmap index scans.

Another possibility...

3.  You might change your process to process multiple records in a
"run" so that you might instead run the query (perhaps via a cursor?)

with LIMIT [Something Bigger than 1].

It does seem mighty expensive to run a 245ms query to find just one
record.  It seems quite likely that you could return the top 100 rows
(LIMIT 100) without necessarily finding it runs in any more time.

Returning 100 tuples in 245ms seems rather more acceptable, no?  :-)
-- 
(format nil "~S@[EMAIL PROTECTED]
" "cbbrowne" "linuxfinances.info")
http://linuxdatabases.info/info/linuxdistributions.html
Rules of the Evil Overlord #32. "I will not fly into a rage and kill a
messenger who brings me bad news  just to illustrate how evil I really
am. Good messengers are hard to come by."
<http://www.eviloverlord.com/>
 




 5 Posts in Topic:
Message queue table..
jesper@[EMAIL PROTECTED]   2008-04-18 19:49:39 
Re: Message queue table..
craig@[EMAIL PROTECTED]   2008-04-19 02:18:40 
Re: Message queue table..
jesper@[EMAIL PROTECTED]   2008-04-18 21:23:09 
Re: Message queue table..
tgl@[EMAIL PROTECTED] (T  2008-04-18 15:27:02 
Re: Message queue table..
Chris Browne <cbbrowne  2008-04-18 15:57:10 

Post A Reply:
  Go here to Signup

AddThis Feed Button


About - Advertising - Contact - Frequently Asked Questions - Privacy Policy - Terms of Use - Signup

Contact
tan12V112 Sun Oct 12 9:36:29 CDT 2008.