Skip site navigation (1) Skip section navigation (2)

Re: mosbench revisited

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Martijn van Oosterhout <kleptog(at)svana(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: mosbench revisited
Date: 2011-08-03 20:10:28
Message-ID: CA+TgmoZi262u_mX3DPt9bRDvMyn3_Wky5NNpE9JR+ky-7icHYw@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Wed, Aug 3, 2011 at 3:38 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On a straight pgbench -S test, you get four system calls per query:
>> recvfrom(), lseek(), lseek(), sendto().  Adding -M prepared eliminates
>> the two lseeks.
>
> [ scratches head... ]  Two?

Yep.

> Is that one for the table and one for its
> lone index, or are we being redundant there?

The former.  Specifically, it appears we're smart enough to only test
the last segment (in this case, the table is large enough that there
is a .1 file, and that's what we're lseeking).

> (If the query ended up being a seqscan, I'd expect a second
> lseek(SEEK_END) when the executor starts up, but I gather from the other
> complaints that the mosbench people were only testing simple indexscan
> queries.)

Yeah, it seems that for a sequential scan we lseek the heap, then the
index, then the heap again; but for index scans we just hit the heap
and the index.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2011-08-03 20:38:16
Subject: Re: mosbench revisited
Previous:From: Tom LaneDate: 2011-08-03 20:03:39
Subject: Re: Further news on Clang - spurious warnings

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group