From: | Yudianto Prasetyo <mr(dot)yudianto(at)gmail(dot)com> |
---|---|
To: | Sergei Kornilov <sk(at)zsrv(dot)org> |
Cc: | Peter Smith <smithpb2250(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: bugs or my fault |
Date: | 2021-09-15 14:16:36 |
Message-ID: | CAN7WH3+o2La0JCSy0d8bxgCLZgF_qEfB5JpV2zSyAYDpMJVTzQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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.
best regards
yudianto
On Wed, Sep 15, 2021 at 8:38 PM Sergei Kornilov <sk(at)zsrv(dot)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
>
From | Date | Subject | |
---|---|---|---|
Next Message | Jef Vervecken | 2021-09-15 14:41:33 | RE: BUG #17192: The csvlog is corrupted |
Previous Message | Sergei Kornilov | 2021-09-15 13:38:53 | Re: bugs or my fault |