I wrote:
> The part of that that seems to be going off the rails is
> this selection of a cutoff frequency below which element values
> will be dropped:
> cutoff_freq = 9 * element_no / bucket_width;
> The first thing I find suspicious here is that the calculation is
> based on element_no
Mark Frost writes:
> We're seeing intermittently very poor performance of a query, when
> occasionally a poor query plan is chosen. We're using Postgres 16.9.
> One suspicious factor when looking at the EXPLAIN ANALYZE output, is a very
> wrong estimated number of rows to be returned from a text
Here's what the OP of the PostgresNIO issue has mentioned about what
performance impact usage of `file_copy` has in his setup
(https://github.com/SwiftPackageIndex/SwiftPackageIndex-Server/pull/3812):
`Series: Default Strategy
Suite AllTests passed after 5.081 seconds
Suite AllTests passed after
On 6/5/25 17:42, Mark Frost wrote:
Is there any good explanation for this behaviour? Preferably we’d like
some way for proper `most_common_elems` statistics to be collected in
our production database, in the hope that influences a good query plan
to always be selected.
most_common_elems h
Hello all,
We’re seeing intermittently very poor performance of a query, when occasionally
a poor query plan is chosen. We’re using Postgres 16.9.
One suspicious factor when looking at the EXPLAIN ANALYZE output, is a very
wrong estimated number of rows to be returned from a text[] column querie
On 6/5/25 16:13, Frédéric Yhuel wrote:
On 6/4/25 16:12, Dimitrios Apostolou wrote:
In general I have noticed most operations are slower after a succesful
pg_restore until VACUUM is complete, which is unfortunate as the
database is huge and it takes days to run. Something I have on my list
On 6/4/25 16:12, Dimitrios Apostolou wrote:
In general I have noticed most operations are slower after a succesful
pg_restore until VACUUM is complete, which is unfortunate as the
database is huge and it takes days to run. Something I have on my list
to try, is whether a COPY FREEZE would al
