Re: tweaking NTUP_PER_BUCKET
| От | Stephen Frost |
|---|---|
| Тема | Re: tweaking NTUP_PER_BUCKET |
| Дата | |
| Msg-id | 20140703181013.GS16422@tamriel.snowman.net обсуждение исходный текст |
| Ответ на | Re: tweaking NTUP_PER_BUCKET (Tomas Vondra <tv@fuzzy.cz>) |
| Ответы |
Re: tweaking NTUP_PER_BUCKET
Re: tweaking NTUP_PER_BUCKET |
| Список | pgsql-hackers |
Tomas,
* Tomas Vondra (tv@fuzzy.cz) wrote:
> However it's likely there are queries where this may not be the case,
> i.e. where rebuilding the hash table is not worth it. Let me know if you
> can construct such query (I wasn't).
Thanks for working on this! I've been thinking on this for a while and
this seems like it may be a good approach. Have you considered a bloom
filter over the buckets..? Also, I'd suggest you check the archives
from about this time last year for test cases that I was using which
showed cases where hashing the larger table was a better choice- those
same cases may also show regression here (or at least would be something
good to test).
Have you tried to work out what a 'worst case' regression for this
change would look like? Also, how does the planning around this change?
Are we more likely now to hash the smaller table (I'd guess 'yes' just
based on the reduction in NTUP_PER_BUCKET, but did you make any changes
due to the rehashing cost?)?
Thanks,
Stephen
В списке pgsql-hackers по дате отправления: