From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Jon Nelson <jnelson+pgsql@jamponi.net>
Cc: pgsql-performance@postgresql.org
Subject: Re: odd postgresql performance (excessive lseek)
Date: Tue, 26 Oct 2010 23:57:41 -0400
Message-ID: <7674.1288151861@sss.pgh.pa.us> (raw)
In-Reply-To: <AANLkTi=8Pkj-mgtcxv-1fyix5zECGock-rOn=G=NDXrU@mail.gmail.com>
References: <AANLkTikS8ptnCVJK+6u-Z3Xh8WMKdgq+T+trdxt3xgYB@mail.gmail.com>
<AANLkTin3qV-dPeu771VLGmbiPPpeHz2oT=0t6CPtaSeS@mail.gmail.com>
<10133.1287498969@sss.pgh.pa.us>
<AANLkTi=8Pkj-mgtcxv-1fyix5zECGock-rOn=G=NDXrU@mail.gmail.com>
Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Oct 19, 2010 at 10:36 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Those lseeks are for the purpose of detecting the current EOF
>> location, ie, finding out whether some other backend has extended the
>> file recently. We could get rid of them, but only at the cost of
>> putting in some other communication mechanism instead.
> I don't get it. Why would be doing that in a tight loop within a
> single backend?
Well, we weren't shown any context whatsoever about what the backend was
actually doing ... but for example the planner likes to recheck the
current physical size of each relation in a query, so that it's working
with an up-to-date number. That could probably be avoided, since an
estimate would be good enough as long as it wasn't horribly stale.
But there are other places that *have* to have the accurate size, like
seqscan startup. I doubt it was as tight a loop as all that. It
wouldn't be hard at all to have an example where those lseeks are the
only operations visible to strace, if all the data the backend needs is
in shared buffers.
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, robertmhaas@gmail.com, jnelson+pgsql@jamponi.net
Subject: Re: odd postgresql performance (excessive lseek)
In-Reply-To: <7674.1288151861@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