Re: Next Steps with Hash Indexes

Поиск
Список
Период
Сортировка
От Dilip Kumar
Тема Re: Next Steps with Hash Indexes
Дата
Msg-id CAFiTN-tJ6vbN3oxrtv4Ak9mo8yvQjHMt4cwXFNCjwHQqOyN9wA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Next Steps with Hash Indexes  (Simon Riggs <simon.riggs@enterprisedb.com>)
Ответы Re: Next Steps with Hash Indexes  (Amit Kapila <amit.kapila16@gmail.com>)
Re: Next Steps with Hash Indexes  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Fri, Jul 23, 2021 at 6:16 PM Simon Riggs
<simon.riggs@enterprisedb.com> wrote:
>
> On Thu, 22 Jul 2021 at 06:10, Amit Kapila <amit.kapila16@gmail.com> wrote:

> Complete patch for hash_multicol.v3.patch attached, slightly updated
> from earlier patch.
> Docs, tests, passes make check.

I was looking into the hash_multicoul.v3.patch, I have a question

  <para>
-  Hash indexes support only single-column indexes and do not allow
-  uniqueness checking.
+  Hash indexes support uniqueness checking.
+  Hash indexes support multi-column indexes, but only store the hash value
+  for the first column, so multiple columns are useful only for uniquness
+  checking.
  </para>

The above comments say that we store hash value only for the first
column,  my question is why don't we store for other columns as well?
I mean we can search the bucket based on the first column hash but the
hashes for the other column could be payload data and we can use that
to match the hash value for other key columns before accessing the
heap, as discussed here[1].  IMHO, this will further reduce the heap
access.

[1] https://www.postgresql.org/message-id/7192.1506527843%40sss.pgh.pa.us


-- 
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com



В списке pgsql-hackers по дате отправления:

Предыдущее
От: torikoshia
Дата:
Сообщение: Re: RFC: Logging plan of the running query
Следующее
От: Thomas Munro
Дата:
Сообщение: Re: Worth using personality(ADDR_NO_RANDOMIZE) for EXEC_BACKEND on linux?