| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
| Cc: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org>, Jim Mlodgenski <jimmy76(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Large files for relations |
| Date: | 2023-05-24 12:33:33 |
| Message-ID: | CA+Tgmob_QjHfZbkoizF=aH4kXH9ih=E2uffvRpBUfNe6D_LGXw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, May 24, 2023 at 2:18 AM Peter Eisentraut
<peter(dot)eisentraut(at)enterprisedb(dot)com> wrote:
> > What I'm hearing is that something simple like this might be more acceptable:
> >
> > * initdb --rel-segsize (cf --wal-segsize), default unchanged
>
> makes sense
+1.
> > * pg_upgrade would convert if source and target don't match
>
> This would be good, but it could also be an optional or later feature.
+1. I think that would be nice to have, but not absolutely required.
IMHO it's best not to overcomplicate these projects. Not everything
needs to be part of the initial commit. If the initial commit happens
2 months from now and then stuff like this gets added over the next 8,
that's strictly better than trying to land the whole patch set next
March.
--
Robert Haas
EDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tomas Vondra | 2023-05-24 13:17:52 | Re: memory leak in trigger handling (since PG12) |
| Previous Message | Robert Haas | 2023-05-24 12:22:08 | Re: Atomic ops for unlogged LSN |