I believe this would be relevant-
https://www.cybertec-postgresql.com/en/optimizer-support-functions/
It seems there is hope down the road to improve those estimates.
Hi,
On 2019-08-20 19:55:56 +0200, Felix Geisendörfer wrote:
> > On 20. Aug 2019, at 19:32, Andres Freund wrote:
> > FWIW, that's not a mis-estimate I'm getting on master ;). Obviously
> > that doesn't actually address your concern...
>
> I suppose this is thanks to the new optimizer support fun
Hi,
> On 20. Aug 2019, at 19:32, Andres Freund wrote:
>
> Hi,
>
> On 2019-08-20 17:11:58 +0200, Felix Geisendörfer wrote:
>>
>> HashAggregate (cost=80020.01..100020.01 rows=200 width=8) (actual
>> time=19.349..23.123 rows=1 loops=1)
>
> FWIW, that's not a mis-estimate I'm getting on mas
Hi,
On 2019-08-20 17:11:58 +0200, Felix Geisendörfer wrote:
> today I debugged a query that was executing about 100x slower than expected,
> and was very surprised by what I found.
>
> I'm posting to this list to see if this might be an issue that should be
> fixed in PostgreSQL itself.
>
> Belo
út 20. 8. 2019 v 17:12 odesílatel Felix Geisendörfer
napsal:
> Hi all,
>
> today I debugged a query that was executing about 100x slower than
> expected, and was very surprised by what I found.
>
> I'm posting to this list to see if this might be an issue that should be
> fixed in PostgreSQL itse
Hi all,
today I debugged a query that was executing about 100x slower than expected,
and was very surprised by what I found.
I'm posting to this list to see if this might be an issue that should be fixed
in PostgreSQL itself.
Below is a simplified version of the query in question:
SET work_me
Yes, adding another index might help reduce the number of rows filtered
--> Rows Removed by Filter: 1308337
Also, make sure you run vacuum analyze on this query.
Regards,
Michael Vitale
Luís Roberto Weck wrote on 8/20/2019 10:58 AM:
Em 20/08/2019 10:54, Barbu Paul - Gheorghe escreveu:
Hello,
Em 20/08/2019 10:54, Barbu Paul - Gheorghe escreveu:
Hello,
I'm running "PostgreSQL 11.2, compiled by Visual C++ build 1914,
64-bit" and I have a query that runs several times per user action
(9-10 times).
The query takes a long time to execute, specially at first, due to
cold caches I think, but
Hello,
I'm running "PostgreSQL 11.2, compiled by Visual C++ build 1914,
64-bit" and I have a query that runs several times per user action
(9-10 times).
The query takes a long time to execute, specially at first, due to
cold caches I think, but the performance varies greatly during a run
of the app