On 3 August 2016 at 20:37, Claudio Freire <klaussfre...@gmail.com> wrote: > On Wed, Aug 3, 2016 at 4:20 AM, Simon Riggs <si...@2ndquadrant.com> wrote: >> == IndexScan == >> >> Note that the executor code for IndexScan appears identical between >> the two optimizations. The difference between duplicate and range LITE >> tuples is needed only at INSERT time (or UPDATE indexed column to a >> new value). >> >> When we do an IndexScan if we see a LITE tuple we do a scan of the >> linepointer ranges covered by this index tuple (which might eventually >> go to a full block scan). For example with bit1 set we would scan 16 >> linepointers (on an 8192 byte block) and with 2 bits set we would scan >> 32 linepointers etc.., not necessarily consecutive ranges. So the >> IndexScan can return potentially many heap rows per index entry, which >> need to be re-checked and may also need to be sorted prior to >> returning them. If no rows are returned we can kill the index pointer, >> just as we do now for btrees, so they will be removed eventually from >> the index without the need for VACUUM. An BitmapIndexScan that sees a >> lossy pointer can also use the lossy TID concept, so we can have >> partially lossy bitmaps. > > Wouldn't this risk scanning rows more than once unless it's part of a > bitmap scan?
It's always the job of the index insert logic to ensure a valid index exists. I'm not sure what you see that changes that here. Say more? -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
