Hi Team,
One of the queries, which retrieves a single record from a table with 16
hash partitions, is taking more than 10 seconds to execute. In contrast,
when we run the same query manually, it completes within milliseconds. This
issue is causing exhaustion of the application pools. Do we have an
On Wed, 2024-11-06 at 22:43 +0530, Ramakrishna m wrote:
> One of the queries, which retrieves a single record from a table with 16 hash
> partitions,
> is taking more than 10 seconds to execute. In contrast, when we run the same
> query manually,
> it completes within milliseconds.
If I read you
>From https://www.postgresql.org/docs/current/sql-copy.html:
|> binary-format file is less portable across machine architectures
and PostgreSQL versions
In my experience, the binary encoding of binding/resultset/copy is
endian neutral (network byte order), so what is the less portable
across machi
On Thu, Oct 31, 2024 at 11:13 AM Rob Sargent wrote:
> Whats the fill factor?
>
No fill factor is specified, so I'm assuming it's the default 90% for
indexes.
FYI we did a REINDEX for the index in question tonight. Since the index was
for last month, there are no more writes to it so we didn't u
It might be worth eliminating the use of cached plans here. Is your app
using prepared statements at all?
Point is that if the optimizer sees the same prepared query , 5 times, the
it locks the plan that it found at that time. This is a good trade off as
it avoids costly planning-time for repetitiv
I have a primary -> standby 1 -> standby 2 setup with all servers running
PG 13.8 (this effort is part of getting on to a newer version, but I think
those details aren't relevant to this problem). The first standby uses
streaming replication from the primary and the second standby is using a
WAL a
