> In short: the error in Aleksander's argument is the assumption that
> shared hashtables have fixed size. That's simply false.
Well this is a bit embarrassing but I have to admit that you are right.
Dynahash code is a bit non-trivial to say the least (let me guess -
there is no point of suggesti
Michael Paquier writes:
> On Fri, Mar 25, 2016 at 9:17 PM, Robert Haas wrote:
>> On Thu, Mar 24, 2016 at 9:50 AM, Aleksander Alekseev
>> wrote:
>>> Currently this procedure has two arguments --- init_size and max_size.
>>> But since shared hash tables have fixed size there is little sense to
>>>
On Fri, Mar 25, 2016 at 9:17 PM, Robert Haas wrote:
> On Thu, Mar 24, 2016 at 9:50 AM, Aleksander Alekseev
> wrote:
>> Currently this procedure has two arguments --- init_size and max_size.
>> But since shared hash tables have fixed size there is little sense to
>> pass two arguments. In fact cur
> No, I think we left it that way on purpose. I don't remember the
> discussion exactly, but I don't think it's hurting anything.
This was a part of original dynahash optimization patch. Since that
patch was about performance improvement and this concrete change is
about refactoring, not performa
On Thu, Mar 24, 2016 at 9:50 AM, Aleksander Alekseev
wrote:
> I would like to continue discussion regarding changing calling
> convention for ShmemInitHash procedure:
>
> http://www.postgresql.org/message-id/CA+TgmoZm=uowt8a_xasfoogwufeelj861ntadiceopyfehv...@mail.gmail.com
>
> Currently this proc
Hello
I would like to continue discussion regarding changing calling
convention for ShmemInitHash procedure:
http://www.postgresql.org/message-id/CA+TgmoZm=uowt8a_xasfoogwufeelj861ntadiceopyfehv...@mail.gmail.com
Currently this procedure has two arguments --- init_size and max_size.
But since sh