Hi,
On 2019-06-20 14:20:27 -0400, Robert Haas wrote:
> On Tue, Jun 18, 2019 at 9:08 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> > Perhaps also the number of slots per backend should be dynamic, so
> > that you have the option to increase it from the current hard-coded
> > value of 2 if you don't want to increase max_connections but find
> > yourself running out of slots (this GUC was a request from Andres but
> > the name was made up by me -- if someone has a better suggestion I'm
> > all ears).
>
> I am not convinced that we really need to GUC-ify this. How about
> just bumping the value up from 2 to say 5?
I'm not sure either. Although it's not great if the only way out for a
user hitting this is to increase max_connections... But we should really
increase the default.
> As Andres observed off-list, it would also be a good idea to allow
> things that are going to gobble memory like hash joins to have some
> input into how much memory gets allocated. Maybe preallocating the
> expected size of the hash is too aggressive -- estimates can be wrong,
> and it could be much smaller.
At least for the case of the hashtable itself, we allocate that at the
predicted size immediately. So a mis-estimation wouldn't change
anything. For the entires, yea, something like you suggest would make
sense.
Greetings,
Andres Freund