On 2/22/23 13:22, Tomas Vondra wrote:
> ...
>
>>> No opinion on these options, but worth a try. Alternatively, we could
>>> try the usual doubling approach - start with a low threshold (and set
>>> the latch frequently), and then gradually increase it up to the 1/4.
>>>
>>> That should work both f
On 2/20/23 19:18, David Geier wrote:
> Hi,
>
> On 2/8/23 11:42, Tomas Vondra wrote:
>> On 2/1/23 14:41, David Geier wrote:
>>
>> Yeah, this is a pretty annoying regression. We already can hit poor
>> behavior when matching rows are not distributed uniformly in the tables
>> (which is what LIMIT
Hi,
On 2/8/23 11:42, Tomas Vondra wrote:
On 2/1/23 14:41, David Geier wrote:
Yeah, this is a pretty annoying regression. We already can hit poor
behavior when matching rows are not distributed uniformly in the tables
(which is what LIMIT costing assumes), and this makes it more likely to
hit si
On 2/1/23 14:41, David Geier wrote:
> Hi hackers,
>
> While migrating from PostgreSQL 14 to 15, we encountered the following
> performance degradation caused by commit 46846433a03dff: "shm_mq: Update
> mq_bytes_written less often", discussion in [1].
>
> The batching can make queries with a LIMIT
Hi hackers,
While migrating from PostgreSQL 14 to 15, we encountered the following
performance degradation caused by commit 46846433a03dff: "shm_mq: Update
mq_bytes_written less often", discussion in [1].
The batching can make queries with a LIMIT clause run significantly
slower compared to
