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

Re: mosbench revisited

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Martijn van Oosterhout <kleptog(at)svana(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: mosbench revisited
Date: 2011-08-03 20:38:16
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Wed, Aug 3, 2011 at 3:38 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> (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.

Sure.  The first two come from the planner getting the table and index
sizes for estimation purposes (look in plancat.c).  The last is done in
heapam.c's initscan().  We could possibly accept stale values for the
planner estimates, but I think heapam's number had better be accurate.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Simon RiggsDate: 2011-08-03 20:44:37
Subject: Locking end of indexes during VACUUM
Previous:From: Robert HaasDate: 2011-08-03 20:10:28
Subject: Re: mosbench revisited

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