Re: [HACKERS] path toward faster partition pruning
От | David Rowley |
---|---|
Тема | Re: [HACKERS] path toward faster partition pruning |
Дата | |
Msg-id | CAKJS1f8RWDvYB8dmh7E4CfkW4Sf+wFD81QKnACXc2JzZKH+nVw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] path toward faster partition pruning (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>) |
Ответы |
Re: [HACKERS] path toward faster partition pruning
|
Список | pgsql-hackers |
On 11 April 2018 at 18:04, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> wrote: > Updated patch attached. Thanks for the updated patch. The only thing I'm not sure about is the chances you've made to the COALESCE function. +CREATE OR REPLACE FUNCTION pp_hashint4_noop(int4, int8) RETURNS int8 AS +$$SELECT coalesce($1, $2)::int8$$ LANGUAGE sql IMMUTABLE; +CREATE OPERATOR CLASS pp_test_int4_ops FOR TYPE int4 USING HASH AS +OPERATOR 1 = , FUNCTION 2 pp_hashint4_noop(int4, int8); +CREATE OR REPLACE FUNCTION pp_hashtext_length(text, int8) RETURNS int8 AS +$$SELECT length(coalesce($1, ''))::int8$$ LANGUAGE sql IMMUTABLE; Why does one default to the seed and the other to an empty string? Shouldn't they both do the same thing? If you were to copy the hash_part.sql you'd just coalesce($1, 0) and coalesce($1, ''), any special reason not to do that? Also just wondering if it's worth adding some verification that we've actually eliminated the correct partitions by backing the tests up with a call to satisfies_hash_partition. I've attached a delta patch that applies to your v2 which does this. Do you think it's worth doing? -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Вложения
В списке pgsql-hackers по дате отправления: