| From: | James Coleman <jtc331(at)gmail(dot)com> | 
|---|---|
| To: | David Rowley <dgrowleyml(at)gmail(dot)com> | 
| Cc: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> | 
| Subject: | Re: Binary search in ScalarArrayOpExpr for OR'd constant arrays | 
| Date: | 2020-04-27 12:40:15 | 
| Message-ID: | CAAaqYe9ZPeFxw126uao4KgAXPO_Exr6t8zeNLSDcXdEf93m53A@mail.gmail.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
On Sun, Apr 26, 2020 at 11:44 PM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
>
> On Mon, 27 Apr 2020 at 15:12, James Coleman <jtc331(at)gmail(dot)com> wrote:
> > While working on this I noticed that dynahash.c line 499 has this assertion:
> >
> > Assert(info->entrysize >= info->keysize);
> >
> > Do you by any chance know why the entry would need to be larger than the key?
>
> Larger or equal. They'd be equal if you the key was the data, since
> you do need to store at least the key.  Looking at the code for
> examples where dynahash is used in that situation, I see
> _hash_finish_split().
Ah, I was thinking of it as key and value being separate sizes added
together rather than one including the other.
Thanks,
James
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2020-04-27 12:49:41 | Re: Poll: are people okay with function/operator table redesign? | 
| Previous Message | Jonathan S. Katz | 2020-04-27 12:34:20 | Re: Poll: are people okay with function/operator table redesign? |