Re: RelOptInfo -> Relation

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: RelOptInfo -> Relation
Date: 2018-02-06 19:23:07
Message-ID: 23824.1517944987@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Fri, Feb 2, 2018 at 7:06 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2018-02-06 19:25:04 pgsql: Avoid valgrind complaint about write() of uninitalized bytes.
Previous Message Tom Lane 2018-02-06 19:11:36 Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)