From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
---|---|
To: | "Sven R(dot) Kunze" <srkunze(at)mail(dot)de>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Indirect indexes |
Date: | 2016-10-21 20:54:15 |
Message-ID: | 5ea2963e-c6cd-8986-34e1-f3f979b86851@BlueTreble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532) mobile: 512-569-9461
From | Date | Subject | |
---|---|---|---|
Next Message | Jim Nasby | 2016-10-21 21:00:04 | Re: emergency outage requiring database restart |
Previous Message | Jim Nasby | 2016-10-21 20:46:40 | Re: Indirect indexes |