Re: Increase value of OUTER_VAR

From: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>
To: Andrey Lepikhov <a(dot)lepikhov(at)postgrespro(dot)ru>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, Amit Langote <amitlangote09(at)gmail(dot)com>
Cc: David Rowley <dgrowleyml(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Increase value of OUTER_VAR
Date: 2021-03-04 13:59:09
Message-ID: b0382c4e-d400-f5a1-e8fa-af592e3670b6@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 3/4/21 8:43 AM, Andrey Lepikhov wrote:
> On 3/3/21 12:52, Julien Rouhaud wrote:
>> On Wed, Mar 3, 2021 at 4:57 PM Amit Langote <amitlangote09(at)gmail(dot)com>
>> wrote:
>>>
>>> On Wed, Mar 3, 2021 at 5:52 PM David Rowley <dgrowleyml(at)gmail(dot)com>
>>> wrote:
>>>> Something like 1 million seems like a more realistic limit to me.
>>>> That might still be on the high side, but it'll likely mean we'd not
>>>> need to revisit this for quite a while.
>>>
>>> +1
>>>
>>> Also, I got reminded of this discussion from not so long ago:
>>>
>>> https://www.postgresql.org/message-id/flat/16302-e45634e2c0e34e97%40postgresql.org
>>>
> Thank you
>>
>> +1
>>
> Ok. I changed the value to 1 million and explained this decision in the
> comment.

IMO just bumping up the constants from ~65k to 1M is a net loss, for
most users. We add this to bitmapsets, which means we're using ~8kB with
the current values, but this jumps to 128kB with this higher value. This
also means bms_next_member etc. have to walk much more memory, which is
bound to have some performance impact for everyone.

Switching to small negative values is a much better idea, but it's going
to be more invasive - we'll have to offset the values in the bitmapsets,
or we'll have to invent a new bitmapset variant that can store negative
values directly (e.g. by keeping two separate bitmaps internally, one
for negative and one for positive values). But that complicates other
stuff too (e.g. bms_next_member now returns -1 to signal "end").

regards

--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message walker 2021-03-04 14:00:11 Re: make coverage-html would fail within build directory separate from source tree
Previous Message Josef Šimánek 2021-03-04 13:44:26 Re: Improvements and additions to COPY progress reporting