Re: Convert MAX_SAOP_ARRAY_SIZE to new guc

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Convert MAX_SAOP_ARRAY_SIZE to new guc
Дата
Msg-id CA+Tgmob2DPa8FeB0-prkXcyTVoR3TUqAHkJQ3BPoRGunB0Q1fw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Convert MAX_SAOP_ARRAY_SIZE to new guc  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Fri, Nov 16, 2018 at 10:11 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I don't think so, because right now they (a) can't get either
> optimization, and/or (b) don't know what either one does or
> how to invoke it.

Sure.  But as soon as they know that, they're just going to try to
figure out how to get the thing they want without the stuff they don't
want.

> A planner-effort knob would be really easy to understand, I think,
> and we'd not be tied to any particular details about what it does.

That's just wishful thinking.  People will want to know what it does,
they'll want that to be documented, and they complain if it changes
from release to release.

I mean, you've often taken the position that people will notice and/or
care deeply if our *C* interfaces change from release to release, and
even moreso in a minor release.  I think you overstate that danger,
but it must be admitted that the danger is not zero.  GUCs, unlike C
functions, are unarguably part of the exposed interface, and the
danger there is considerably more, at least IMHO.

> One of the first things I'd replace with such a knob is
> join_collapse_limit/from_collapse_limit, which is by no stretch
> of the imagination a corner case.

True.  So then you'll have people who can't get sufficiently-high
collapse limits without enabling a bunch of other stuff they don't
care about, or on the other hand have to raise the collapse limits
higher than makes sense for them to get the other optimizations that
they want.  They also won't be able to use the hack where you set
join_collapse_limit=1 to force a join ordering any more.  And the
mapping of the 1..infinity collapse limit space onto the 1..10 planner
effort space is going to be basically totally arbitrary.  There is no
hope at all that you're going to pick values that everyone likes.

I think it might be reasonable to set various individual GUCs to
values that mean "use the autoconfigure default" and then provide a
planner-strength GUC that varies that default.  But I believe that
depriving people of the ability to control the settings individually
is bound to produce complaints, both for things where we already
expose them (like the collapse limits) and for things where we don't
(like $SUBJECT).

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: Speeding up INSERTs and UPDATEs to partitioned tables
Следующее
От: Tom Lane
Дата:
Сообщение: Re: BUG #15160: planner overestimates number of rows in join when there are more than 200 rows coming from CTE