Re: [HACKERS] path toward faster partition pruning

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)com>, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, Amit Langote <amitlangote09(at)gmail(dot)com>, Rajkumar Raghuwanshi <rajkumar(dot)raghuwanshi(at)enterprisedb(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-02-08 17:58:21
Message-ID: 20180208175821.5rpwefzhrbi2wss6@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Robert Haas wrote:
> On Wed, Feb 7, 2018 at 3:42 AM, Ashutosh Bapat
> <ashutosh(dot)bapat(at)enterprisedb(dot)com> wrote:

> > partition.c seems to have two kinds of functions 1. that build and
> > manage relcache, creates quals from bounds etc. which are metadata
> > management kind 2. partition bound comparison functions, and other
> > optimizer related functions. May be we should divide the file that
> > way. The first category code remains in catalog/ as it is today. The
> > second catagory functions move to optimizer/.
> It would be sensible to separate functions that build and manage data
> in the relcache from other functions. I think we should consider
> moving the existing functions of that type from partition.c to
> src/backend/utils/cache/partcache.c.

FWIW I've been thinking that perhaps we need some other separation of
code better than statu quo. The current partition.c file includes stuff
for several modules and ISTM all these new patches are making more and
more of a mess. So +1 to the general idea of splitting things up.
Maybe partcache.c is not ambitious enough, but it seems a good first

Álvaro Herrera
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2018-02-08 18:01:38 Re: Proposal: partition pruning by secondary attributes
Previous Message Robert Haas 2018-02-08 17:57:33 Re: Query running for very long time (server hanged) with parallel append