From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Amit Langote <amitlangote09(at)gmail(dot)com>, David Steele <david(at)pgmasters(dot)net>, Pavel Biryukov <79166341370(at)yandex(dot)ru>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: posgres 12 bug (partitioned table) |
Date: | 2021-04-21 21:48:18 |
Message-ID: | 20210421214818.2ylmenjtu6gsyqx7@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
Hi,
On 2021-04-21 17:38:53 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > I don't really see us getting rid of something like ctid as a generic
> > concept across AMs - there's just too many places that need a way to
> > reference a specific tuple. However, I think we ought to change how much
> > code outside of AMs know about what tids mean. And, although that's a
> > significant lift on its own, we ought to make at least the generic
> > representation variable width.
>
> It seems like it might not be that hard to convert ctid generically
> into a uint64, where heaps and heap-related indexes only use 6 bytes
> of it.
Yep.
> Variable-width I agree would be a very big complication added on top,
> and I'm not quite convinced that we need it.
I can see three (related) major cases where variable width tids would be
quite useful:
1) Creating an index-oriented-table AM would harder/more
limited with just an 8 byte tid
2) Supporting "indirect" indexes (i.e. indexes pointing to a primary
key, thereby being much cheaper to maintain when there are updates),
would require the primary key to map to an 8 byte integer.
3) Global indexes would be a lot easier if we had variable width tids
(but other ways of addressing the issue are possible).
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Yi Sun | 2021-04-21 23:07:41 | pg_cron leak memory bug, please help, thanks |
Previous Message | Tom Lane | 2021-04-21 21:38:53 | Re: posgres 12 bug (partitioned table) |
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2021-04-21 22:12:48 | Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY |
Previous Message | Tom Lane | 2021-04-21 21:38:53 | Re: posgres 12 bug (partitioned table) |