From: | Markus Schiltknecht <markus(at)bluegap(dot)ch> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | Gokulakannan Somasundaram <gokul007(at)gmail(dot)com>, tomas(at)tuxteam(dot)de, Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>, pgsql-hackers(at)postgresql(dot)org, Andrew Sullivan <ajs(at)crankycanuck(dot)ca> |
Subject: | Re: Dynamic Partitioning using Segment Visibility Maps |
Date: | 2008-01-09 14:53:39 |
Message-ID: | 4784DFF3.9040701@bluegap.ch |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Simon Riggs wrote:
> Hmmm. I think it fits rather neatly with BitmapIndexScans. It would be
> easy to apply the index condition and/or filters to see which segments
> are excluded and then turn off bits in the bitmap appropriately.
Yeah, good point.
> Not fully sure about IndexScans yet. I don't think it would be worth
> trying to apply SE until we estimated we would return say 100 rows. It
> needs to be able to work without slowing down the common path.
Yup.
>> Or
>> put it another way: SE is an optimization for sequential scans. For
>> tables where it works well, it could possibly replace the index entirely.
>
> True
>
>> Without the index, you would rely on SE to always be able to exclude
>> enough segments, so that the seq scan is less expensive than an index
>> scan with the following table lookups.
>
> It would have to be a very fat index scan for so large a table...
..for SE to be faster than an index scan, you mean? Yes.
Regards
Markus
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2008-01-09 14:57:19 | Re: Some notes about the index-functions security vulnerability |
Previous Message | Simon Riggs | 2008-01-09 14:49:49 | Re: Dynamic Partitioning using Segment Visibility Maps |