From: | Claudio Freire <klaussfreire(at)gmail(dot)com> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Lossy Index Tuple Enhancement (LITE) |
Date: | 2016-08-03 19:37:58 |
Message-ID: | CAGTBQpY6ZtmYG2b7m_xS5BMjxCW-+=-T1FNj8rZG4-s1vQuCQw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Aug 3, 2016 at 4:20 AM, Simon Riggs <simon(at)2ndquadrant(dot)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?
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-08-03 19:41:54 | Re: Implementing full UTF-8 support (aka supporting 0x00) |
Previous Message | Álvaro Hernández Tortosa | 2016-08-03 19:36:26 | Re: Implementing full UTF-8 support (aka supporting 0x00) |