Re: [HACKERS] path toward faster partition pruning - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: [HACKERS] path toward faster partition pruning
Date
Msg-id 20180405223512.euhn52qm7bcqp2hy@alvherre.pgsql
Whole thread Raw
In response to Re: [HACKERS] path toward faster partition pruning  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: [HACKERS] path toward faster partition pruning  (David Rowley <david.rowley@2ndquadrant.com>)
Re: [HACKERS] path toward faster partition pruning  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Re: [HACKERS] path toward faster partition pruning  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
List pgsql-hackers
I seems pretty clear that putting get_matching_partitions() in
catalog/partition.c is totally the wrong thing; it belongs wholly in
partprune. I think the reason you put it there is that it requires
access to a lot of internals that are static in partition.c.  In the
attached not yet cleaned version of the patch, I have moved a whole lot
of what you added to partition.c to partprune.c; and for the functions
and struct declarations that were required to make it work, I created
catalog/partition_internal.h.

I changed a lot of code also, but cosmetic changes only.

I'll clean this up a bit more now, and try to commit shortly (or early
tomorrow); wanted to share current status now in case I have to rush
out.

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

Attachment

pgsql-hackers by date:

Previous
From: Andrew Gierth
Date:
Subject: Checkpoint not retrying failed fsync?
Next
From: David Rowley
Date:
Subject: Re: Removing useless DISTINCT clauses