Re: Increase value of OUTER_VAR
Tomas Vondra <tomas.vondra@enterprisedb.com>
From: Tomas Vondra <tomas.vondra@enterprisedb.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
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:34:51Z
Lists: pgsql-hackers
On 3/4/21 4:16 PM, Tom Lane wrote: > 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. > Hmmm, I don't know. I mostly assumed that if I do pull_varnos() it would include those values. But maybe that's not supposed to happen. > 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. > OK regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Commits
-
Remove arbitrary 64K-or-so limit on rangetable size.
- e3ec3c00d85b 15.0 landed
-
More cleanups of the include files
- 105409746499 7.1.1 cited