Re: Message queue table..

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jesper Krogh <jesper(at)krogh(dot)cc>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Message queue table..
Date: 2008-04-18 19:27:02
Message-ID: 7590.1208546822@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Jesper Krogh <jesper(at)krogh(dot)cc> 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).

> Limit (cost=0.00..0.09 rows=1 width=106) (actual
> time=245.273..245.274 rows=1 loops=1)
> -> Index Scan using workqueue_job_funcid_priority_idx on job
> (cost=0.00..695291.80 rows=8049405 width=106) (actual
> time=245.268..245.268 rows=1 loops=1)
> Index Cond: (funcid = 4)
> Filter: ((run_after <= 1208442668) AND (grabbed_until <=
> 1208442668) AND ("coalesce" = 'Efam'::text))
> Total runtime: 245.330 ms

Well, what that's doing in English is: scan all the rows with funcid =
4, in priority order, until we hit the first one satisfying the filter
conditions. Apparently there are a lot of low-priority rows that have
funcid = 4 but not the other conditions.

If it's the "coalesce" condition that's the problem, an index on
(funcid, coalesce, priority) --- or (coalesce, funcid, priority) ---
would probably help. I'm not sure there's a simple fix if it's
the other conditions that are really selective.

regards, tom lane

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message James Mansion 2008-04-18 19:55:31 full_page_write and also compressed logging
Previous Message Jesper Krogh 2008-04-18 19:23:09 Re: Message queue table..