Re: RelOptInfo -> Relation

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: RelOptInfo -> Relation
Дата
Msg-id 23824.1517944987@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: RelOptInfo -> Relation  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: RelOptInfo -> Relation
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)
Следующее
От: Andres Freund
Дата:
Сообщение: Why does load_external_function() return PGFunction?