2011/5/10 Kevin Grittner <kevin.gritt...@wicourts.gov>:
> Simon Riggs <si...@2ndquadrant.com> wrote:
>> The typical speed up for non-covered indexes will come when we
>> access a very large table (not in cache) via an index scan that is
>> smaller than a bitmapindex scan. Will we be able to gauge
>> selectivities sufficiently accurately to be able to pinpoint that
>> during optimization? How will we know that the table is not in
>> cache? Or is this an optimisation in the executor for a bitmapheap
>> scan?
> I would continue to object to using current cache contents for plan
> choice because of plan instability and the fact that an odd initial
> cache load could skew plans in a bad direction indefinitely.  I do
> agree (and have already posted) that I think the hardest part of
> this might be developing a good cost model.  I doubt that's an
> insoluble problem, especially since it is something we can refine
> over time as we gain experience with the edge cases.

you will have the same possible instability in planning with the
index(-only?) scan because we may need to access heap anyway and this
needs is based on estimation, or I miss something ? I understood the
idea was just to bypass the heap access *if* we can for *this*

In reality, I am not really scared by plan instability because of a
possible PG/OS cache estimation. The percentages remain stable in my
observations ... I don't know yet how it will go for vis map.

And, we already have plan instability currently, which is *good* : at
some point a seq scan is better than an bitmap heap scan. Because the
relation size change and because ANALYZE re-estimate the distribution
of the data. I will be very happy to issue ANALYZE CACHE as I have to
ANALYZE temp table for large query if it allows the planner to provide
me the best plan in some scenario...but this is another topic, sorry
for the digression..

Cédric Villemain               2ndQuadrant
http://2ndQuadrant.fr/     PostgreSQL : Expertise, Formation et Support

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to