| From: | Simon Riggs <simon(dot)riggs(at)enterprisedb(dot)com> |
|---|---|
| To: | Maxim Orlov <orlovmg(at)gmail(dot)com> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Zhang Mingli <zmlpostgres(at)gmail(dot)com>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com>, Aleksander Alekseev <aleksander(at)timescale(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Stephen Frost <sfrost(at)snowman(dot)net>, Alexander Korotkov <aekorotkov(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Ilya Anfimov <ilan(at)tzirechnoy(dot)com> |
| Subject: | Re: Add 64-bit XIDs into PostgreSQL 15 |
| Date: | 2022-11-24 17:42:31 |
| Message-ID: | CANbhV-F=qi7M0SGevAcGaw6bBBWyz0NCHrh4EHZbReCX3fDCtg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, 21 Oct 2022 at 17:09, Maxim Orlov <orlovmg(at)gmail(dot)com> wrote:
> Reviews and opinions are very welcome!
I'm wondering whether the safest way to handle this is by creating a
new TAM called "heap64", so that all storage changes happens there.
(Obviously there are still many other changes in core, but they are
more easily fixed).
That would reduce the code churn around "heap", allowing us to keep it
stable while we move to the brave new world.
Many current users see stability as one of the greatest strengths of
Postgres, so while I very much support this move, I wonder if this
gives us a way to have both stability and innovation at the same time?
--
Simon Riggs http://www.EnterpriseDB.com/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ankit Kumar Pandey | 2022-11-24 17:57:11 | Re: Questions regarding distinct operation implementation |
| Previous Message | Alvaro Herrera | 2022-11-24 17:34:49 | Re: Fix for visibility check on 14.5 fails on tpcc with high concurrency |