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: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, Rajkumar Raghuwanshi <rajkumar(dot)raghuwanshi(at)enterprisedb(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Beena Emerson <memissemerson(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [Sender Address Forgery]Re: [Sender Address Forgery]Re: [HACKERS] path toward faster partition pruning |
Date: | 2018-01-17 09:19:45 |
Message-ID: | CAKJS1f_Y_7e+gRk1bUQPHcynkJ6X7tuy+nAwE6qOvqEdox49tw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 17 January 2018 at 17:05, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> wrote:
> 6. Which brings me to; why do we need match_clauses_to_partkey at all?
> classify_partition_bounding_keys seems to do all the work
> match_clauses_to_partkey does, plus more. Item #3 above is caused by
> an inconsistency between these functions. What benefit does
> match_clauses_to_partkey give? I might understand if you were creating
> list of clauses matching each partition key, but you're just dumping
> everything in one big list which causes
> classify_partition_bounding_keys() to have to match each clause to a
> partition key again, and classify_partition_bounding_keys is even
> coded to ignore clauses that don't' match any key, so it makes me
> wonder what is match_clauses_to_partkey actually for?
I started to look at this and ended up shuffling the patch around a
bit to completely remove the match_clauses_to_partkey function.
I also cleaned up some of the comments and shuffled some fields around
in some of the structs to shrink them down a bit.
All up, this has saved 268 lines of code in the patch.
src/backend/catalog/partition.c | 296 ++++++++++++++++-----------
src/backend/optimizer/path/allpaths.c | 368 ++--------------------------------
2 files changed, 198 insertions(+), 466 deletions(-)
It's had very minimal testing. Really I've only tested that the
regression tests pass.
I also fixed up the bad assumption that IN lists will contain Consts
only which hopefully fixes the crash I reported earlier.
I saw you'd added a check to look for contradicting IS NOT NULL
clauses when processing an IS NULL clause, but didn't do anything for
the opposite case. I added code for this so it behaves the same
regardless of the clause order.
Can you look at my changes and see if I've completely broken anything?
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
Attachment | Content-Type | Size |
---|---|---|
faster_partition_prune_v20_delta_drowley.patch | application/octet-stream | 33.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Etsuro Fujita | 2018-01-17 10:32:35 | Re: [HACKERS] postgres_fdw bug in 9.6 |
Previous Message | Amit Langote | 2018-01-17 09:10:50 | Re: pgsql: Centralize json and jsonb handling of datetime types |