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
|
Список | 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 по дате отправления: