On Thu, 10 Oct 2019 at 01:07, Behrang Saeedzadeh wrote:
>
> This is a follow up to
> https://www.postgresql.org/message-id/flat/CAERAJ%2B-1buiJ%2B_JWEo0a9Ao-CVMWpgp%3DEnFx1dJtnB3WmMi2zQ%40mail.gmail.com
>
> The query (generated by Hibernate) got a bit more complex and performance
> degraded agai
Are you prefixing this auto generated query with set join_collapse_limit =
30, or are you changing the default and reloading config? That is, can you
impact ONLY this query with these config changes? I wouldn't assume so, so
any hack/query hint like turning off hashjoins (which seem to be chosen
in
This is a follow up to
https://www.postgresql.org/message-id/flat/CAERAJ%2B-1buiJ%2B_JWEo0a9Ao-CVMWpgp%3DEnFx1dJtnB3WmMi2zQ%40mail.gmail.com
The query (generated by Hibernate) got a bit more complex and performance
degraded again. I have uploaded all the details here (with changed table
names, etc
Thanks for the tip!
Regards,
Behrang (sent from my mobile)
On Mon, Oct 7, 2019, 07:37 Tomas Vondra
wrote:
> On Tue, Oct 01, 2019 at 11:42:33PM +1000, Behrang Saeedzadeh wrote:
> >Thanks. That eliminated the bottleneck!
> >
> >Any ideas why adding ORDER BY to the subquery also changes the plan i
On Tue, Oct 01, 2019 at 11:42:33PM +1000, Behrang Saeedzadeh wrote:
Thanks. That eliminated the bottleneck!
Any ideas why adding ORDER BY to the subquery also changes the plan in a
way that eliminates the bottleneck?
IIRC the ORDER BY clause makes it impossible to "collapse" the subquery
into
Thanks. That eliminated the bottleneck!
Any ideas why adding ORDER BY to the subquery also changes the plan in a
way that eliminates the bottleneck?
Best regards,
Behrang Saeedzadeh
blog.behrang.org
On Tue, 1 Oct 2019 at 23:27, Tom Lane wrote:
> Behrang Saeedzadeh writes:
> > On my machine,
Behrang Saeedzadeh writes:
> On my machine, this query that is generated by Hibernate runs in about 57
> ms on MySQL 8 but it takes more than 1 second to run on PostgreSQL:
> SELECT bills.id AS bill_id,
>bills.bill_date AS bill_date,
>bills.bill_number
