|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|
|Views:||Raw Message | Whole Thread | Download mbox|
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
|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|