From: | Felix Geisendörfer <felix(at)felixge(dot)de> |
---|---|
To: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
Cc: | "pgsql-performa(dot)" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Extremely slow HashAggregate in simple UNION query |
Date: | 2019-08-22 09:06:37 |
Message-ID: | 7B66B20A-6807-4FC6-9CA7-C80E311E8539@felixge.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
> On 21. Aug 2019, at 20:26, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
>
> As noted elsewhere, v12 thwarts your attempts to deliberately design the bad estimates. You can still get them, you just have 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 estimation problems 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 return true. 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 extension if I need more flexibility in the future!
Thanks
Felix
From | Date | Subject | |
---|---|---|---|
Next Message | Barbu Paul - Gheorghe | 2019-08-22 11:51:50 | Re: Erratically behaving query needs optimization |
Previous Message | Pavel Stehule | 2019-08-22 05:08:23 | Re: Extremely slow HashAggregate in simple UNION query |