Re: [HACKERS] path toward faster partition pruning
Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>
On Tue, Feb 27, 2018 at 3:03 PM, Amit Langote
<Langote_Amit_f8@lab.ntt.co.jp> wrote:
> Attached an updated version in which I incorporated some of the revisions
> that David Rowley suggested to OR clauses handling (in partprune.c) that
> he posted as a separate patch on the run-time pruning thread [1].
Some comments on 0001.
partnatts != part_scheme->partnatts)
continue;
- /* Match the partition key types. */
+ /*
+ * Match the partition key types and partitioning-specific collations.
+ */
We are comparing opfamily and opclass input type as well, but this comment
doesn't explicitly mention those like it mentions collation. Instead, I think
we should just say, "Match partition key type properties"
You had commented on "advanced partition matching code" about asserting that
parsupfuncs also match. Robert too has expressed similar opinion upthread. May
be we should at least try to assert that the function OIDs match.
- Oid *parttypcoll; /* OIDs of collations of partition keys. */
+
+ /*
+ * We store both the collation implied by the partition key's type and the
+ * one specified for partitioning. Values in the former are used as
+ * varcollid in the Vars corresponding to simple column partition keys so
+ * as to make them match corresponding Vars appearing elsewhere in the
+ * query tree. Whereas, the latter is used when actually comparing values
+ * against partition bounds datums, such as, when doing partition pruning.
+ */
+ Oid *parttypcoll;
+ Oid *partcollation;
As you have already mentioned upthread only partcollation is needed, not
parttypcoll.
/* Cached information about partition key data types. */
int16 *parttyplen;
bool *parttypbyval;
+
+ /*
+ * Cached array of partitioning comparison functions' fmgr structs. We
+ * don't compare these when trying to match two partition schemes.
+ */
I think this comment should go away. The second sentence doesn't explain why
and if it did so it should do that in find_partition_scheme() not here.
partsupfunc is another property of partition keys that is cached like
parttyplen, parttypbyval. Why does it deserve a separate comment when others
don't?
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
Commits
-
Fix assorted partition pruning bugs
- d758d9702e2f 11.0 landed
-
Make gen_partprune_steps static
- d1e2cac5ff7e 11.0 landed
-
Remove useless 'default' clause
- c775fb9e18ac 11.0 landed
-
Reorganize partitioning code
- da6f3e45ddb6 11.0 landed
-
Use custom hash opclass for hash partition pruning
- fafec4cce814 11.0 landed
-
Blindly attempt to fix sepgsql tests broken due to 9fdb675fc5.
- 4f813c7203e0 11.0 landed
-
Attempt to fix endianess issues in new hash partition test.
- 40e42e1024c5 11.0 landed
-
Faster partition pruning
- 9fdb675fc5d2 11.0 landed
-
For partitionwise join, match on partcollation, not parttypcoll.
- 2af28e603319 11.0 landed
-
Revise API for partition bound search functions.
- f724022d0ae0 11.0 landed
-
Revise API for partition_rbound_cmp/partition_rbound_datum_cmp.
- b0229235564f 11.0 landed
-
Fix possible crash in partition-wise join.
- f069c91a5793 11.0 cited
-
Refactor code for partition bound searching
- 9aef173163ae 11.0 landed
-
New C function: bms_add_range
- 84940644de93 11.0 landed
-
Add extensive tests for partition pruning.
- 8d4e70a63bf8 11.0 landed
-
Add null test to partition constraint for default range partitions.
- 7b88d63a9122 11.0 cited
-
Remove BufFile's isTemp flag.
- 11e264517dff 11.0 cited
-
Make OWNER TO subcommand mention consistent
- bf54c0f05c0a 11.0 cited
-
Fix index matching for operators with mixed collatable/noncollatable inputs.
- cb37c291060d 9.2.0 cited