Re: Extremely slow HashAggregate in simple UNION query
От | Felix Geisendörfer |
---|---|
Тема | Re: Extremely slow HashAggregate in simple UNION query |
Дата | |
Msg-id | 7B66B20A-6807-4FC6-9CA7-C80E311E8539@felixge.de обсуждение исходный текст |
Ответ на | Re: Extremely slow HashAggregate in simple UNION query (Jeff Janes <jeff.janes@gmail.com>) |
Список | pgsql-performance |
> On 21. Aug 2019, at 20:26, Jeff Janes <jeff.janes@gmail.com> wrote: > > As noted elsewhere, v12 thwarts your attempts to deliberately design the bad estimates. You can still get them, you justhave to work a bit harder at it: > > CREATE FUNCTION j (bigint, bigint) returns setof bigint as $$ select generate_series($1,$2) $$ rows 1000 language sql; Yeah, that's awesome! I didn't know about this until I ran into this issue, I'll definitely be using it for future estimationproblems that are difficult to fix otherwise! > I've made an extension which has a function which always returns true, but lies about how often it is expected to returntrue. See the attachment. With that, you can fine-tune the planner. > > CREATE EXTENSION pg_selectivities ; Very cool and useful : )! I think in most cases I'll be okay with declaring a function with a static ROWS estimate, but I'll consider your extensionif I need more flexibility in the future! Thanks Felix
В списке pgsql-performance по дате отправления: