Re: [HACKERS] path toward faster partition pruning

Robert Haas <robertmhaas@gmail.com>

From: Robert Haas <robertmhaas@gmail.com>
To: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
Cc: David Rowley <david.rowley@2ndquadrant.com>, Rajkumar Raghuwanshi <rajkumar.raghuwanshi@enterprisedb.com>, Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>, Jesper Pedersen <jesper.pedersen@redhat.com>, Amit Langote <amitlangote09@gmail.com>, Dilip Kumar <dilipbalaut@gmail.com>, Beena Emerson <memissemerson@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2018-02-26T18:27:58Z
Lists: pgsql-hackers
On Sun, Feb 25, 2018 at 11:10 PM, Amit Langote
<Langote_Amit_f8@lab.ntt.co.jp> wrote:
> I think I'm convinced that partopcintype OIDs can be used where I thought
> parttypid ones were necessary.  The pruning patch uses the respective OID
> from this array when extracting the datum from an OpExpr to be compared
> with the partition bound datums.  It's sensible, I now think, to require
> the extracted datum to be of partition opclass declared input type, rather
> than the type of the partition key involved.  So, I removed the parttypid
> that I'd added to PartitionSchemeData.
>
> Updated the comments to make clear the distinction between and purpose of
> having both parttypcoll and partcollation.  Also expanded the comment
> about partsupfunc a bit.

I don't think this fundamentally fixes the problem, although it does
narrow it.  By requiring partcollation to match across every relation
with the same PartitionScheme, you're making partition-wise join fail
to work in some cases where it previously did.  Construct a test case
where parttypcoll matches and partcollation doesn't; then, without the
patch, the two relations will have the same PartitionScheme and thus
be eligible for a partition-wise join, but with the patch, they will
have different PartitionSchemes and thus won't.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL 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.