Re: [HACKERS] path toward faster partition pruning

From: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
To: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
Cc: Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, Rajkumar Raghuwanshi <rajkumar(dot)raghuwanshi(at)enterprisedb(dot)com>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, Amit Langote <amitlangote09(at)gmail(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Beena Emerson <memissemerson(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] path toward faster partition pruning
Date: 2018-04-04 03:21:06
Message-ID: CAKJS1f9s4ajRFQWWKcHjbiLfL0+_kvN_uUhtfYDaGmXeWGY0cQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 4 April 2018 at 13:13, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> wrote:
> There might be another issue with the patch too, but I'll send a
> separate email about that.

In the current version of the patch the following comment exists:

/*
* Fall-through for a NOT clause, which is handled in
* match_clause_to_partition_key().
*/

The only real handling of NOT clauses is in
match_boolean_partition_clause() which just handles NOT(true) or
NOT(false).

It's true that the const simplification code will generally rewrite
most NOT(clause) to use the negator operator, but if the operator does
not have a negator it can't do this.

We probably don't have any built-in operators which are members of a
btree opclass which have no negator, but it's simple enough to modify
the citext extension by commenting out the NEGATOR lines in
citext--1.4--1.5.sql.

create extension citext;
create table listp(a citext) partition by list(a citext_pattern_ops);
create table listp_1 partition of listp for values in('1');
explain select * from listp where not (a ~>~ '0' and a ~<~ '2');
QUERY PLAN
--------------------------------------------------------------------------
Append (cost=0.00..36.45 rows=1209 width=32)
-> Seq Scan on listp_1 (cost=0.00..30.40 rows=1209 width=32)
Filter: ((NOT (a ~>~ '0'::citext)) OR (NOT (a ~<~ '2'::citext)))
(3 rows)

At the moment pruning does not work for this case at all. Perhaps it should?

I imagine it might be possible to re-work the COMBINE_INVERT code so
that it becomes a flag of the combine step rather than a step operator
type. It should then be possible to invert COMBINE_UNION for
NOT(clause1 OR clause2) and COMBINE_INTERSECT on NOT(clause1 AND
clause2).

IOW, it might not take too many lines of code to put this right.
Probably the bulk of the work would be writing a test with a btree
opclass that will allow us to have the planner not invert the clause
during const folding.

--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ashutosh Bapat 2018-04-04 03:38:57 Re: Comment update in BuildTupleFromCStrings()
Previous Message Peter Geoghegan 2018-04-04 03:08:32 Re: WIP: Covering + unique indexes.