On Wed, Feb 1, 2017 at 4:38 AM, Merlin Moncure wrote:
> I was just troubleshooting a strange performance issue with pg_trgm
> (greatest extension over) that ran great in testing but poor in
> production following a 9.6 in place upgrade from 9.2. By poor I mean
> 7x slower. Problem was resolved b
Albe Laurenz wrote
> […]
> Experiment with raising join_collapse_limit and from_collapse_limit to 11.
Thank you, this solve the problem.
> Alternatively, optimize the join order by hand and don't tune the parameters.
What is surprising is that there is no apparent/logical optimal strategy.
Bes
Just a wild guess, but did you check your random source? We had similar
problems in Oracle and had to switch to /dev/urandom. It can be done with a
system variable setting.
On Wed, Feb 1, 2017, 7:52 AM Vucomir Ianculov wrote:
> can anyone help me with my problem?
> i'm really don't know from whe
Hi Merlin:
Any EXPLAIN on the query affected? size of indexes before and after reindex?
Regards,
Daniel.
> El 1 feb 2017, a las 13:38, Merlin Moncure escribió:
>
> I was just troubleshooting a strange performance issue with pg_trgm
> (greatest extension over) that ran great in testing but po
can anyone help me with my problem?
i'm really don't know from when the problem can be.
- Original Message -
From: "Vucomir Ianculov"
To: "Tom Lane"
Cc: pgsql-performance@postgresql.org
Sent: Saturday, January 28, 2017 12:03:55 PM
Subject: Re: [PERFORM] pgsql connection timeone
I was just troubleshooting a strange performance issue with pg_trgm
(greatest extension over) that ran great in testing but poor in
production following a 9.6 in place upgrade from 9.2. By poor I mean
7x slower. Problem was resolved by ALTER EXTENSION UPDATE followed by
a REINDEX on the impacted t
