| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Daniel Verite <daniel(at)manitou-mail(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Kevin Grittner <kgrittn(at)gmail(dot)com> |
| Subject: | Re: Add parallelism and glibc dependent only options to reindexdb |
| Date: | 2019-07-28 16:34:18 |
| Message-ID: | 20190728163418.bolniw34m7u3dhio@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2019-07-28 10:07:27 -0400, Tom Lane wrote:
> In the long run, might we ever switch to 64-bit OIDs? I dunno.
> Now that we kicked them out of user tables, it might be feasible,
> but by the same token there's not much pressure to do it.
Depends on the the table, I'd say. Having toast tables have 64bit ids,
and not advance the oid counter, would be quite the advantage over the
current situation. Toasting performance craters once the oid counter has
wrapped. But obviously there are upgrade problems there - presumably
we'd need 'narrow" and 'wide' toast tables, or such.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2019-07-28 16:42:44 | Re: ANALYZE: ERROR: tuple already updated by self |
| Previous Message | Tom Lane | 2019-07-28 16:07:41 | Re: Testing LISTEN/NOTIFY more effectively |