Re: WIP: Upper planner pathification
От | Tom Lane |
---|---|
Тема | Re: WIP: Upper planner pathification |
Дата | |
Msg-id | 10958.1456845736@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: WIP: Upper planner pathification (Teodor Sigaev <teodor@sigaev.ru>) |
Ответы |
Re: WIP: Upper planner pathification
|
Список | pgsql-hackers |
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. regards, tom lane
В списке pgsql-hackers по дате отправления: