From: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | 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 06:18:13 |
Message-ID: | 7c7bf3b0-5ed6-c707-3ed9-5f5372241188@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 24.05.23 02:34, Thomas Munro wrote:
> Thanks all for the feedback. It was a nice idea and it *almost*
> works, but it seems like we just can't drop segmented mode. And the
> automatic transition schemes I showed don't make much sense without
> that goal.
>
> What I'm hearing is that something simple like this might be more acceptable:
>
> * initdb --rel-segsize (cf --wal-segsize), default unchanged
makes sense
> * 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.
Maybe that should be a different mode, like
--copy-and-adjust-as-necessary, so that users would have to opt into
what would presumably be slower than plain --copy, rather than being
surprised by it, if they unwittingly used incompatible initdb options.
> I would probably also leave out those Windows file API changes, too.
> --rel-segsize would simply refuse larger sizes until someone does the
> work on that platform, to keep the initial proposal small.
Those changes from off_t to pgoff_t? Yes, it would be good to do
without those. Apart of the practical problems that have been brought
up, this was a major annoyance with the proposed patch set IMO.
> I would probably leave the experimental copy_on_write() ideas out too,
> for separate discussion in a separate proposal.
right
From | Date | Subject | |
---|---|---|---|
Next Message | Jakub Wartak | 2023-05-24 08:19:26 | Re: memory leak in trigger handling (since PG12) |
Previous Message | Benjamin Coutu | 2023-05-24 05:59:45 | Re: Insertion Sort Improvements |