From: Tom Lane <tgl@sss.pgh.pa.us>
To: Brian Karlak <zenkat@metaweb.com>
Cc: Jeff Janes <jeff.janes@gmail.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: maintaining a reference to a fetched row
Date: Wed, 04 Nov 2009 15:43:47 -0500
Message-ID: <20917.1257367427@sss.pgh.pa.us> (raw)
In-Reply-To: <82545852-CE9E-4B0D-ABAB-B628C888D086@metaweb.com>
References: <22AC581D-50D1-4863-9FDE-35EDDB171269@metaweb.com>
<f67928030911040847j434be6b0w59cf4a6218829ec3@mail.gmail.com>
<82545852-CE9E-4B0D-ABAB-B628C888D086@metaweb.com>
Brian Karlak <zenkat@metaweb.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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: tgl@sss.pgh.pa.us, zenkat@metaweb.com, jeff.janes@gmail.com
Subject: Re: maintaining a reference to a fetched row
In-Reply-To: <20917.1257367427@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox