Re: [HACKERS] path toward faster partition pruning
Amit Langote <langote_amit_f8@lab.ntt.co.jp>
Attachments
- v35-0001-Add-partsupfunc-to-PartitionSchemeData.patch (text/plain) patch v35-0001
- v35-0002-Faster-partition-pruning.patch (text/plain) patch v35-0002
- v35-0003-Add-only-unpruned-partitioned-child-rels-to-part.patch (text/plain) patch v35-0003
Thanks Ashutosh and David for reviewing. Replying to both.
On 2018/02/28 20:25, Ashutosh Bapat wrote:
> 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"
Sounds good, done.
> 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.
I guess you're referring to this email of mine:
https://www.postgresql.org/message-id/e681c283-5fc6-b1c6-1bb9-7102c37e2d55%40lab.ntt.co.jp
Note that I didn't say that we should Assert the equality of partsupfunc
members themselves, but rather whether we could add a comment explaining
why we don't. Although, like you say, we could Assert the equality of
function OIDs, so added a block like this:
+ /*
+ * If partopfamily and partopcintype matched, must have the same
+ * partition comparison functions. Note that we cannot reliably
+ * Assert the equality of function structs themselves for they might
+ * be different across PartitionKey's, so just Assert for the function
+ * OIDs.
+ */
+#ifdef USE_ASSERT_CHECKING
+ {
+ int i;
+
+ for (i = 0; i < partkey->partnatts; i++)
+ Assert(partkey->partsupfunc[i].fn_oid ==
+ part_scheme->partsupfunc[i].fn_oid);
+ }
+#endif
> - 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.
This hunk is gone after rebasing over 2af28e603319 (For partitionwise
join, match on partcollation, not parttypcoll) that was committed earlier
today.
> /* 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?
Replaced that comment with:
+ /* Cached information about partition comparison functions. */
As mentioned above, I already added a comment in find_partition_scheme().
On 2018/02/28 20:35, David Rowley wrote:
> Micro review of v34:
>
> 1. Looks like you've renamed the parttypid parameter in the definition
> of partkey_datum_from_expr and partition_cmp_args, but not updated the
> declaration too.
>
> +static bool partkey_datum_from_expr(Oid parttypid, Expr *expr, Datum
*value);
>
> +static bool
> +partkey_datum_from_expr(Oid partopcintype, Expr *expr, Datum *value)
>
> +static bool partition_cmp_args(Oid parttypid, Oid partopfamily,
> + PartClause *pc, PartClause *leftarg, PartClause *rightarg,
> + bool *result);
>
> +static bool
> +partition_cmp_args(Oid partopcintype, Oid partopfamily,
> + PartClause *pc, PartClause *leftarg, PartClause *rightarg,
> + bool *result)
Oops, forgot about the declarations. Fixed.
> 2. In prune_append_rel_partitions(), it's not exactly illegal, but int
> i is declared twice in different scopes. Looks like there's no need
> for the inner one.
Removed the inner one.
Attached updated patches.
Thanks,
Amit
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