Re: bugs or my fault
| От | Yudianto Prasetyo |
|---|---|
| Тема | Re: bugs or my fault |
| Дата | |
| Msg-id | CAN7WH3+o2La0JCSy0d8bxgCLZgF_qEfB5JpV2zSyAYDpMJVTzQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: bugs or my fault (Sergei Kornilov <sk@zsrv.org>) |
| Список | pgsql-bugs |
Hello,
thanks for the information about hash partitions.
I just think that the hash partition will not speed up the Query, because we don't know the location of certain rows such as the range partition or the list partition. For example, transactions in 2000 with a range partition, we can query the "transaction2000" partition table faster than we can query the "transaction" table.
yudianto
thanks for the information about hash partitions.
I just think that the hash partition will not speed up the Query, because we don't know the location of certain rows such as the range partition or the list partition. For example, transactions in 2000 with a range partition, we can query the "transaction2000" partition table faster than we can query the "transaction" table.
best regards
On Wed, Sep 15, 2021 at 8:38 PM Sergei Kornilov <sk@zsrv.org> wrote:
We don't do just id % 3, we calculate some hash value from partition key (id) and route the tuple according this hash value. Such condition for your example:
select *, satisfies_hash_partition('myschema.customers'::regclass, 3, 0, id) as modulus3_remainder0_target_partition from myschema.cust0;
Can't illustrate more at the SQL level due to the lack of a uint64 calculations. At C level we are here: https://github.com/postgres/postgres/blob/REL_13_STABLE/src/backend/partitioning/partbounds.c#L4595
regards, Sergei
В списке pgsql-bugs по дате отправления: