Re: Increase value of OUTER_VAR

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Tomas Vondra <tomas.vondra@enterprisedb.com>
Cc: Andrey Lepikhov <a.lepikhov@postgrespro.ru>, Julien Rouhaud <rjuju123@gmail.com>, Amit Langote <amitlangote09@gmail.com>, David Rowley <dgrowleyml@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-03-04T15:16:49Z
Lists: pgsql-hackers
Tomas Vondra <tomas.vondra@enterprisedb.com> writes:
> 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.

Hmm, do we really have any places that include OUTER_VAR etc in
bitmapsets?  They shouldn't appear in relid sets, for sure.
I agree though that if they did, this would have bad performance
consequences.

I still think the negative-special-values approach is better.
If there are any places that that would break, we'd find out about
it in short order, rather than having a silent performance lossage.

			regards, tom lane



Commits

  1. Remove arbitrary 64K-or-so limit on rangetable size.

  2. More cleanups of the include files