From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Brian Karlak <zenkat(at)metaweb(dot)com> |
Cc: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: maintaining a reference to a fetched row |
Date: | 2009-11-04 20:43:47 |
Message-ID: | 20917.1257367427@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Brian Karlak <zenkat(at)metaweb(dot)com> writes:
> On Nov 4, 2009, at 8:47 AM, Jeff Janes wrote:
>> Why would the index scan take 1 ms two of the times it is done but 5ms
>> the third time? Isn't it the same index scan each time? Or does the
>> change in queue.status change the plan?
> The final update is a different query -- just a plain old update by ID:
> UPDATE queue_proc set status = 'proc' where id = %s ;
> This update by ID takes ~2.5ms, which means it's where the framework
> is spending most of its overhead.
Well, if SELECT FROM queue_proc where id = %s takes 1ms and the update
takes 2.5ms, then you've got 1.5ms going into updating the row, which
means it's not going to get a whole lot faster by switching to some
other WHERE condition. Maybe you should look at cutting back on indexes
and/or triggers attached to this table.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Crooke | 2009-11-04 21:18:46 | vacuum'ing toast crumbs, detecting dangling transactions |
Previous Message | Brian Karlak | 2009-11-04 17:41:54 | Re: maintaining a reference to a fetched row |