Re: [HACKERS] [POC] hash partitioning

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [HACKERS] [POC] hash partitioning
Дата
Msg-id CA+TgmoZQJ_ij8vVHr1vrL1w8VvOdEcGrQLLc1iHwusxbuqx-mQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] [POC] hash partitioning  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Ответы Re: [HACKERS] [POC] hash partitioning  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Список pgsql-hackers
On Thu, Sep 28, 2017 at 1:54 AM, Amit Langote
<Langote_Amit_f8@lab.ntt.co.jp> wrote:
> I looked into how satisfies_hash_partition() works and came up with an
> idea that I think will make constraint exclusion work.  What if we emitted
> the hash partition constraint in the following form instead:
>
> hash_partition_mod(hash_partition_hash(key1-exthash, key2-exthash),
>                    <mod>) = <rem>
>
> With that form, constraint exclusion seems to work as illustrated below:
>
> \d+ p0
> <...>
> Partition constraint:
> (hash_partition_modulus(hash_partition_hash(hashint4extended(a,
> '8816678312871386367'::bigint)), 4) = 0)
>
> -- note only p0 is scanned
> explain select * from p where
> hash_partition_modulus(hash_partition_hash(hashint4extended(a,
> '8816678312871386367'::bigint)), 4) = 0;

What we actually want constraint exclusion to cover is SELECT * FROM p
WHERE a = 525600;

As Amul says, nobody's going to enter a query in the form you have it
here.  Life is too short to take time to put queries into bizarre
forms.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

Предыдущее
От: chenhj
Дата:
Сообщение: Re: [HACKERS] [PATCH]make pg_rewind to not copy useless WALfiles
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] SendRowDescriptionMessage() is slow for queries with alot of columns