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 по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: Extremely slow HashAggregate in simple UNION query
Следующее
От: Barbu Paul - Gheorghe
Дата:
Сообщение: Re: Erratically behaving query needs optimization