Horton

Re: [HACKERS] path toward faster partition pruning

Alvaro Herrera <alvherre@alvh.no-ip.org>

View thread View on postgr.es
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: David Rowley <david.rowley@2ndquadrant.com>
Cc: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>, Jesper Pedersen <jesper.pedersen@redhat.com>, Robert Haas <robertmhaas@gmail.com>, Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>, Rajkumar Raghuwanshi <rajkumar.raghuwanshi@enterprisedb.com>, Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>, 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-04-06T14:54:39Z
Lists: pgsql-hackers 
Alvaro Herrera wrote:

> Yeah.  Looking at this function, I noticed it tests for BooleanTest, and
> falls back to checking "not_clause" and a few equals.  Does it make
> sense if the clause is a SAOP?  I added this assert:
> 	Assert(IsA(clause, BooleanTest) ||
> 		   IsA(clause, BoolExpr) ||
> 		   IsA(clause, RelabelType));
> 
> and it failed:
> #3  0x0000556cf04505db in match_boolean_partition_clause (partopfamily=424, 
>     clause=0x556cf1041670, partkey=0x556cf1042218, rightop=0x7ffe520ec068)
>     at /pgsql/source/master/src/backend/optimizer/util/partprune.c:2159
> 2159		Assert(IsA(clause, BooleanTest) ||
> (gdb) print *clause
> $1 = {type = T_ScalarArrayOpExpr}
> 
> I'm not sure whether or not this function can trust that what's incoming
> must absolutely be only those node types.

So this is what I need for current regression tests not to crash
anymore:

	Assert(IsA(clause, BooleanTest) ||
		   IsA(clause, BoolExpr) ||
		   IsA(clause, RelabelType) ||
		   IsA(clause, ScalarArrayOpExpr) ||
		   IsA(clause, OpExpr) ||
		   IsA(clause, Var));

I'm not confident in my ability to write code to handle all possible
cases right now (obviously there must be more cases that are not covered
by current regression tests), so I'll leave it without the assert since
it handles a couple of the useful cases, but I suspect it could stand
some more improvement.

I guess the question is, how interesting is boolean partitioning?  I bet
it has its uses.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

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.