Message-ID: <4808F51D.40102@krogh.cc>
Date: Fri, 18 Apr 2008 21:23:09 +0200
From: Jesper Krogh <jesper@krogh.cc>
User-Agent: Thunderbird 2.0.0.12 (X11/20080227)
MIME-Version: 1.0
To: Craig Ringer <craig@postnewspapers.com.au>
CC: pgsql-performance@postgresql.org
Subject: Re: Message queue table..
References: <4808DF33.8000008@krogh.cc>
	<4808E600.3060108@postnewspapers.com.au>
In-Reply-To: <4808E600.3060108@postnewspapers.com.au>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Craig Ringer wrote:
> Jesper Krogh wrote:
>>
>> Hi.
>>
>> 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)
> 
> You mean all records of interest, right, not all records in the table?

Actually all the records.. since all the other virtual queues currently 
are empty.

> What indexes do you have in place? What's the schema? Can you post a "\d 
> tablename" from psql?
> 
>> # 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

I found that removing the funcid from the order by made it use a better 
index. (priority, run_after, grabbed_until)  that probably makes sense 
since the funcid doesnt give any value in the index at all.

thanks for leading me back on track.

Jesper

-- 
Jesper