From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Closing some 8.4 open items |
Date: | 2009-04-08 15:50:19 |
Message-ID: | 603c8f070904080850k4c4b8ddeq184b98f4f88b0776@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Apr 8, 2009 at 10:33 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Wed, Apr 8, 2009 at 1:17 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> And please note that we think bitmap scans are the larger part of
>>> the win anyway. What's left undone there is some marginal mopup.
>
>> Can you elaborate on this? I'm fuzzy on why index scans can't benefit
>> from this as much as bitmap index scans.
>
> The main point is that the planner will prefer a bitmap scan for any
> query that's estimated to return more than quite a small number of rows.
> (In my experience the cutover point is in the single digits.) So
> there's just not that much room to win for plain indexscans. Their
> principal application is really for fetching single rows, a case where
> prefetch is entirely useless because you have nothing to overlap.
That makes sense, but what about the nestloop-over-inner-indexscan case?
...Robert
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-04-08 15:59:49 | Re: Closing some 8.4 open items |
Previous Message | Merlin Moncure | 2009-04-08 15:46:07 | Re: Array types |