Re: Indirect indexes - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Indirect indexes
Date
Msg-id CANP8+j+ERoVPn6gFevWqm6U=SGAeg3JhCASpLDLysKnUeViujg@mail.gmail.com
Whole thread Raw
In response to Re: Indirect indexes  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Indirect indexes  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On 19 October 2016 at 18:40, Bruce Momjian <bruce@momjian.us> wrote:
> On Wed, Oct 19, 2016 at 07:23:28PM +0530, Pavan Deolasee wrote:
>>     AFAICS, even without considering VACUUM, indirect indexes would be always
>>     used with recheck.
>>     As long as they don't contain visibility information.  When indirect
>>     indexed column was updated, indirect index would refer same PK with
>>     different index keys.
>>     There is no direct link between indirect index tuple and heap tuple, only
>>     logical link using PK.  Thus, you would anyway have to recheck.
>>
>>
>>
>> I agree. Also, I think the recheck mechanism will have to be something like
>> what I wrote for WARM i.e. only checking for index quals won't be enough and we
>> would actually need to verify that the heap tuple satisfies the key in the
>> indirect index.
>
> I personally would like to see how far we get with WARM before adding
> this feature that requires a DBA to evaluate and enable it.

Assuming WARM is accepted, that *might* be fine.

What we should ask is what is the difference between indirect indexes
and WARM and to what extent they overlap.

My current understanding is that WARM won't help you if you update
parts of a JSON document and/or use GIN indexes, but is effective
without needing to add a new index type and will be faster for
retrieval than indirect indexes.

So everybody please chirp in with benefits or comparisons.

-- 
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Andreas Joseph Krogh
Date:
Subject: Re: Move pg_largeobject to a different tablespace *without* turning on system_table_mods.
Next
From: Bruce Momjian
Date:
Subject: Re: Remove vacuum_defer_cleanup_age