Re: POC: GROUP BY optimization
От | Tomas Vondra |
---|---|
Тема | Re: POC: GROUP BY optimization |
Дата | |
Msg-id | a16ac766-f898-3299-28fd-5aabfa6f308d@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: POC: GROUP BY optimization (David Rowley <dgrowleyml@gmail.com>) |
Ответы |
Re: POC: GROUP BY optimization
|
Список | pgsql-hackers |
On 8/18/22 03:32, David Rowley wrote: > On Thu, 18 Aug 2022 at 02:46, Tomas Vondra > <tomas.vondra@enterprisedb.com> wrote: >> So I don't think the current costing is wrong, but it certainly is more >> complex. But the test does not test what it intended - I have two ideas >> how to make it work: >> >> 1) increase the number of rows in the table >> >> 2) increase cpu_operator_cost (for that one test?) >> >> 3) tweak the costing somehow, to increase the cost a bit > > Why not, 4) SET parallel_setup_cost = 0; there are plenty of other > places we do just that so we get a parallel plan without having to > generate enough cost to drown out the parallel worker startup cost. > > Here are a couple of patches to demo the idea. > Yeah, that's an option too. I should have mentioned it along with the cpu_operator_cost. BTW would you mind taking a look at the costing? I think it's fine, but it would be good if someone not involved in the patch takes a look. regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: