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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-08-03 20:38:16 | Re: mosbench revisited |
Previous Message | Tom Lane | 2011-08-03 20:03:39 | Re: Further news on Clang - spurious warnings |