Re: RelOptInfo -> Relation - Mailing list pgsql-hackers

From Tom Lane
Subject Re: RelOptInfo -> Relation
Date
Msg-id 23824.1517944987@sss.pgh.pa.us
Whole thread Raw
In response to Re: RelOptInfo -> Relation  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: RelOptInfo -> Relation
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Feb 2, 2018 at 7:06 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I'm disinclined to monkey with the way this works without someone
>> presenting hard evidence that it creates enough of a performance problem
>> to be worth spending a significant amount of time changing it.  Up to
>> now I don't think I've ever noticed plancat.c being a large fraction
>> of planner runtime, though of course that might depend on the test case.

> If we're going to have to change this at some point (and I bet we
> are), I'd rather do it before people jam even more stuff into the
> current system rather than wait until it gets totally out of hand.

While I'm prepared to believe that this *could* be a problem, I repeat
that you've offered no hard evidence that it actually *is* a problem,
or might become one in the future.  We could easily expend a significant
amount of effort here for no real return.

            regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)
Next
From: Andres Freund
Date:
Subject: Why does load_external_function() return PGFunction?