Re: WIP: Upper planner pathification

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: WIP: Upper planner pathification
Дата
Msg-id CANP8+jLKwo8=+uc=jWQM_W3xVv2a23h1xJG0goAjuJdHj4to0Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: WIP: Upper planner pathification  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: WIP: Upper planner pathification  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список pgsql-hackers
On 2 March 2016 at 13:47, Robert Haas <robertmhaas@gmail.com> wrote:
On Tue, Mar 1, 2016 at 10:22 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Teodor Sigaev <teodor@sigaev.ru> writes:
>>> I do not think the patch will make a lot of performance difference as-is;
>>> its value is more in what it will let us do later.  There are a couple of
>
>> Yep, for now on my notebook (best from 5 tries):
>> % pgbench -i -s 3000
>> % pgbench  -s 3000 -c 4 -j 4 -P 1 -T 60
>> HEAD    569 tps
>> patched 542 tps
>> % pgbench  -s 3000 -c 4 -j 4 -P 1 -T 60 -S
>> HEAD    9500 tps
>> patched 9458 tps
>
>> Looks close to measurement error, but may be explained increased amount of work
>> for planning. Including, may be, more complicated path tree.
>
> I think the default pgbench queries are too simple to have any possible
> benefit from this patch.  It does look like you're seeing some extra
> planning time, which I think is likely due to redundant construction
> of PathTargets.  The new function set_pathtarget_cost_width() is not
> very cheap, and in order to minimize the delta in this patch I did
> not worry much about avoiding duplicate calls of it.  That's another
> thing in a long list of things to do later ;-).  There might be other
> pain points I haven't recognized yet.

Yikes.  The read-only test is an 0.5% hit which isn't great, but the
read-write test is about 5% which I think is clearly not OK.  What's
your plan for doing something about that?

Whether artefact of test, or real problem, clearly something fixable.

ISTM that we are clearly "going for it"; everybody agrees we should apply the patch now.

The longer we hold off on applying it, the longer we wait for dependent changes. 

My vote is apply it early (i.e. now!) and clean up as we go.

--
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: WIP: Upper planner pathification
Следующее
От: Tom Lane
Дата:
Сообщение: Re: WIP: Upper planner pathification