Re: Large files for relations

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: Large files for relations
Дата
Msg-id 7c7bf3b0-5ed6-c707-3ed9-5f5372241188@enterprisedb.com
обсуждение исходный текст
Ответ на Re: Large files for relations  (Thomas Munro <thomas.munro@gmail.com>)
Ответы Re: Large files for relations  (Robert Haas <robertmhaas@gmail.com>)
Re: Large files for relations  (Stephen Frost <sfrost@snowman.net>)
Список 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




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Benjamin Coutu
Дата:
Сообщение: Re: Insertion Sort Improvements
Следующее
От: Jakub Wartak
Дата:
Сообщение: Re: memory leak in trigger handling (since PG12)