Thread: AW: AW: pg_index.indislossy

AW: AW: pg_index.indislossy

From
Zeugswetter Andreas SB
Date:
> > > > > > > Can someone tell me what we use indislossy for?
> > > >
> > > > Ok, so the interpretation of this field is:
> > > >     A match in the index needs to be reevaluated in the heap tuple data,
> > > >     since a match in the index does not necessarily mean, that the heap tuple
> > > >     matches.
> > > >     If the heap tuple data matches, the index must always match.
> > 
> > AFAIK, this is true for all indexes in PostgreSQL, because index rows
> > don't store the transactions status.  Of course those are two different
> > underlying reasons why a heap lookup is always necessary, but there
> > shouldn't be any functional difference in the current implementation.
> 
> Seems it is something they added for the index abstraction and not for
> practical use by PostgreSQL.

Why, you do not need to call the comparison function on the heap data
if the index is not lossy, saves some CPU cycles.

Andreas


Re: AW: AW: pg_index.indislossy

From
Bruce Momjian
Date:
> 
> > > > > > > > Can someone tell me what we use indislossy for?
> > > > >
> > > > > Ok, so the interpretation of this field is:
> > > > >     A match in the index needs to be reevaluated in the heap tuple data,
> > > > >     since a match in the index does not necessarily mean, that the heap tuple
> > > > >     matches.
> > > > >     If the heap tuple data matches, the index must always match.
> > > 
> > > AFAIK, this is true for all indexes in PostgreSQL, because index rows
> > > don't store the transactions status.  Of course those are two different
> > > underlying reasons why a heap lookup is always necessary, but there
> > > shouldn't be any functional difference in the current implementation.
> > 
> > Seems it is something they added for the index abstraction and not for
> > practical use by PostgreSQL.
> 
> Why, you do not need to call the comparison function on the heap data
> if the index is not lossy, saves some CPU cycles.

Because we don't know of the tuples expired status until we check the
heap.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026