From: | "Sven R(dot) Kunze" <srkunze(at)mail(dot)de> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Indirect indexes |
Date: | 2016-10-22 16:08:19 |
Message-ID: | ed09525b-2772-77a1-b1aa-5598767e475d@mail.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 21.10.2016 22:54, Jim Nasby wrote:
> On 10/21/16 2:48 PM, Sven R. Kunze wrote:
>>
>>> You don't need that limitation (and vacuum will be simpler) if you add
>> the PK as another key, akin to:
>>>
>>> CREATE INDIRECT INDEX idx ON tab (a, b, c);
>>>
>>> turns into
>>>
>>> CREATE INDEX idx ON tab (a, b, c, pk);
>>
>>
>> I know I am late to this point but I wanted to present my mere user's
>> point of view.
>>
>> First I liked it, as does not introduce yet another syntax to learn.
>
> I believe you mis-understood what Claudio was saying. He's not
> suggesting an index with the PK on the end magically becomes an indirect
> index; he was saying that a "simple" way to overcome the 6 byte index
> TID limitation would be to store the PK as part of the index key. He
> used existing DDL to illustrate that, but that was just for
> illustration, not how this would actually be implemented.
Alright. Thanks for clarifying. :)
Cheers,
Sven
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-10-22 16:38:47 | Re: On conflict update & hint bits |
Previous Message | David Steele | 2016-10-22 16:00:58 | Re: Renaming of pg_xlog and pg_clog |