Re: pg_dump versus hash partitioning

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pg_dump versus hash partitioning
Дата
Msg-id 1440373.1675299790@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pg_dump versus hash partitioning  (David Rowley <dgrowleyml@gmail.com>)
Ответы Re: pg_dump versus hash partitioning  (Andrew Dunstan <andrew@dunslane.net>)
Список pgsql-hackers
David Rowley <dgrowleyml@gmail.com> writes:
> Digging into the history a bit, I found [2] and particularly [3] that
> seem to indicate this option was thought about due to concerns about
> hash functions not returning consistent results on different
> architectures. I suspect it might have been defaulted to load into the
> leaf partitions for performance reasons, however. I mean, why else
> would you?
> [3] https://www.postgresql.org/message-id/CA%2BTgmoZFn7TJ7QBsFatnuEE%3DGYGdZSNXqr9489n5JBsdy5rFfA%40mail.gmail.com

Hah ... so we went over almost exactly this same ground in 2017.
The consensus at that point seemed to be that actual problems
would be rare enough that we'd not need to impose the overhead
of --load-via-partition-root by default.  Now, AFAICS that was
based on exactly zero hard evidence, as to either the frequency
of actual problems or the cost of --load-via-partition-root.
Our optimism about the former seems to have been mostly borne out,
given the lack of complaints since then; but I still think our
pessimism about the latter is on shaky grounds.

Anyway, after re-reading the old thread I wonder if my first instinct
(force --load-via-partition-root for enum hash cases only) was the
best compromise after all.  I'm not sure how painful it is to get
pg_dump to detect such cases, but it's probably possible.

            regards, tom lane



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

Предыдущее
От: Thomas Munro
Дата:
Сообщение: Re: CI and test improvements
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Worth using personality(ADDR_NO_RANDOMIZE) for EXEC_BACKEND on linux?