Horton

Re: [HACKERS] path toward faster partition pruning

Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>

View thread View on postgr.es
From: Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>
To: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
Cc: Robert Haas <robertmhaas@gmail.com>, Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>, Jesper Pedersen <jesper.pedersen@redhat.com>, David Rowley <david.rowley@2ndquadrant.com>, Amit Langote <amitlangote09@gmail.com>, Rajkumar Raghuwanshi <rajkumar.raghuwanshi@enterprisedb.com>, Dilip Kumar <dilipbalaut@gmail.com>, Beena Emerson <memissemerson@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2018-02-07T08:42:51Z
Lists: pgsql-hackers 
On Tue, Feb 6, 2018 at 3:25 PM, Amit Langote
<Langote_Amit_f8@lab.ntt.co.jp> wrote:
>
> Agreed.  partition.c has gotten quite big and actually more than half of
> the code that this patch adds really seems to belong outside of it.
>
>> And it seems to me that the code you're adding
>> here is really quite similar to what we've already got in that
>> directory -- for example, predtest.c, which currently does partition
>> pruning, lives there; so does clauses.c, whose evaluate_expr facility
>> this patch wants to use; so does relnode.c, which the other patches
>> modify; and in general this looks an awful lot like other optimizer
>> logic that decomposes clauses.  I'm open to other suggestions but I
>> don't think adding all of this directly into partition.c is a good
>> plan.
>
> Agreed.
>
> A partprune.c in the optimizer's util directory seems like a good place.

partprune.c looks to much tied to one feature. I am sure that the
functions used for partition pruning can be used by other
optimizations as well.

partition.c seems to have two kinds of functions 1. that build and
manage relcache, creates quals from bounds etc. which are metadata
management kind 2. partition bound comparison functions, and other
optimizer related functions. May be we should divide the file that
way. The first category code remains in catalog/ as it is today. The
second catagory functions move to optimizer/.

-- 
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company

Commits

  1. Fix assorted partition pruning bugs

  2. Make gen_partprune_steps static

  3. Remove useless 'default' clause

  4. Reorganize partitioning code

  5. Use custom hash opclass for hash partition pruning

  6. Blindly attempt to fix sepgsql tests broken due to 9fdb675fc5.

  7. Attempt to fix endianess issues in new hash partition test.

  8. Faster partition pruning

  9. For partitionwise join, match on partcollation, not parttypcoll.

  10. Revise API for partition bound search functions.

  11. Revise API for partition_rbound_cmp/partition_rbound_datum_cmp.

  12. Fix possible crash in partition-wise join.

  13. Refactor code for partition bound searching

  14. New C function: bms_add_range

  15. Add extensive tests for partition pruning.

  16. Add null test to partition constraint for default range partitions.

  17. Remove BufFile's isTemp flag.

  18. Make OWNER TO subcommand mention consistent

  19. Fix index matching for operators with mixed collatable/noncollatable inputs.