Hi,
previous discussion at [1].
Initially I wanted to send this to the docs mailing list, but while testing
this further I think this is more an issue with the planner.
The example(s) in the docs for bloom filters
(https://www.postgresql.org/docs/current/bloom.html) cannot be reproduced at
al
>In your example, the bottleneck is calling the function f1. So you need to
>check only this function. It is not important if other functions or
>>procedures do database lookups.
>Or if it does just one database lookup, then you can use SQL language. I
>repeat, PL/pgSQL is not good for ultra ve
pá 30. 7. 2021 v 9:12 odesílatel Daniel Westermann (DWE)
mailto:daniel.westerm...@dbi-services.com>>
napsal:
Hi,
we have a customer which was migrated from Oracle to PostgreSQL 12.5 (I know,
the latest version is 12.7). The migration included a lot of PL/SQL code.
Attached a very simp
Hi,
we have a customer which was migrated from Oracle to PostgreSQL 12.5 (I know,
the latest version is 12.7). The migration included a lot of PL/SQL code.
Attached a very simplified test case. As you can see there are thousands, even
nested calls to procedures and functions. The test case does
From: Tom Lane
Sent: Thursday, April 15, 2021 17:00
To: Daniel Westermann (DWE)
Cc: pgsql-performance@lists.postgresql.org
Subject: Re: Strange behavior once statistics are there
>I'd suggest trying to flatten these to be regular joins, ie
>try to bring up persons6_ and stufen
Hi,
I currently have a strange behavior once statistics are collected. This is the
statement (I don't know the application, the statement is as it is):
explain (analyze, buffers) select distinct standardzi4_.code as col_0_0_,
person1_.personalnummer as col_1_0_,
