On 16/06/2020 18:28, Marc Cousin wrote:
> Oh, sorry about that, I forgot to detail this. I tested on both 10.13 (which
> is the production environment on which we faced this), and on 12.3, with the
> same problem.
>
> On 16/06/2020 17:51, Tom Lane wrote:
>> Marc Cousin
Oh, sorry about that, I forgot to detail this. I tested on both 10.13 (which is
the production environment on which we faced this), and on 12.3, with the same
problem.
On 16/06/2020 17:51, Tom Lane wrote:
> Marc Cousin writes:
>> Of course, what happens here is that the histogram says
Hi,
We're having an issue with planner performance when doing large deletes at the
same time as we have long running transactions, from what we gathered, because
of the scan to find the actual minimum and maximum values of the table.
Instead of trying to explain what happens, here is a very sim
Hi,
I spent a little bit of time trying to explain the problem we are facing
clearly, and provide a reproducible benchmark.
So here it is.
What triggered our investigation is that we have a PostgreSQL cluster
containing about 15 databases, most of them being used as sources for logical
repli
On 29/06/2019 00:23, Julien Rouhaud wrote:
> On Fri, Jun 28, 2019 at 10:16 PM Tom Lane wrote:
>>
>> Tomas Vondra writes:
>>> On Fri, Jun 28, 2019 at 03:03:19PM -0400, Tom Lane wrote:
I not only don't want that function in indxpath.c, I don't even want
it to be known/called from there.
Hi all,
I'm trying to extend pg_tap/pg_tapgen in order to be able to check that
two databases have the exact same constraints (for all available types
of constraints).
I am wondering if there is a better way to check that two constraints
are equal than using pg_get_constraintdef, which is
