Re: Performance implications of partitioning by UUIDv7 range in PostgreSQL v18

Поиск
Список
Период
Сортировка
От David Rowley
Тема Re: Performance implications of partitioning by UUIDv7 range in PostgreSQL v18
Дата
Msg-id CAApHDvrD7TgbgVp0ab91Zp-99YQSkwXhE9S0H8jeMNZw7SgGRQ@mail.gmail.com
обсуждение исходный текст
Ответ на Performance implications of partitioning by UUIDv7 range in PostgreSQL v18  (Jonathan Reis <jon.reis@conevity.com>)
Список pgsql-performance
On Wed, 22 Oct 2025 at 23:53, Jonathan Reis <jon.reis@conevity.com> wrote:
> Will the planner efficiently prune partitions when queries filter by UUIDv7 ranges (e.g., WHERE id BETWEEN
uuidv7_floor(timestamp1)AND uuidv7_floor(timestamp2) that align with time periods?
 

It depends. What are timestamp1 and timestamp2? If they're constants,
then the planner can prune away tables outside of the given range as
you're partitioning by range (id). Don't expect any pruning if you
were to do something like uuid_extract_timestamp(id) when partitioned
by "id". The function is just a blackbox to the pruning code. If
timestamp1 and timestamp2 are columns from another table, then the
planner won't do any pruning (the executor might).

It should be trivial to mock up some tables and look at EXPLAIN to see
what the planner can and can't do for pruning. Just keep in mind the
executor also can prune both during executor startup, which is the
first opportunity to know the results of stable functions (such as
NOW()) and external parameter values (for PREPARE statements).
Pruning can also occur during execution as parameter values being used
in clauses containing the partition key in Append/MergeAppend change.

More details about that in:
https://www.postgresql.org/docs/current/ddl-partitioning.html#DDL-PARTITION-PRUNING

David



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