Re: [HACKERS] GSoC 2017: weekly progress reports (week 4) and patchfor hash index
| От | Alexander Korotkov |
|---|---|
| Тема | Re: [HACKERS] GSoC 2017: weekly progress reports (week 4) and patchfor hash index |
| Дата | |
| Msg-id | CAPpHfdvz3g7j+EjhceGX6SfQstU_uE3yayckieOz+RTv0OVRDQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [HACKERS] GSoC 2017: weekly progress reports (week 4) and patchfor hash index (Thomas Munro <thomas.munro@enterprisedb.com>) |
| Ответы |
Re: [HACKERS] GSoC 2017: weekly progress reports (week 4) and patchfor hash index
|
| Список | pgsql-hackers |
On Fri, Mar 2, 2018 at 6:57 AM, Thomas Munro <thomas.munro@enterprisedb.com> wrote:
My thought experiments about pseudo-pages and avoiding the split stuff
were not intended to get the patch kicked out. I thought for a while
that hash indexes were a special case and could benefit from
dispensing with those trickier problems. Upon further reflection, for
interesting size hash indexes pure hash value predicate tags wouldn't
be much better. Furthermore, if we do decide we want to use using x %
max_predicate_locks_per_relation to avoid having to escalate to
relation predicate locks at the cost of slightly higher collision rate
then we should consider that for the whole system (including heap page
predicate locking), not just hash indexes. Please consider those
ideas parked for now.
OK. While our potential pseudo-pages are identified as
"hash_value % some_constant_modulus", real bucket pages are very roughly
identified as "hash_value % number_of_index_pages". So, page number is
adoptive to index size, despite it costs us handling page split. In the same way,
locking in other index access methods is adoptive to an index size, so
that should be considered as useful feature which should be present in hash index
as well.
------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
В списке pgsql-hackers по дате отправления: