Re: maintaining a reference to a fetched row

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

In response to

Browse pgsql-performance by date

  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