Re: A better way than tweaking NTUP_PER_BUCKET

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: A better way than tweaking NTUP_PER_BUCKET
Дата
Msg-id CA+U5nMKvOYyVfgxYmRicqeKa3WD-Nhk=Jpj2meEP7fV0NDMF2g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: A better way than tweaking NTUP_PER_BUCKET  (Stephen Frost <sfrost@snowman.net>)
Ответы Re: A better way than tweaking NTUP_PER_BUCKET  (Stephen Frost <sfrost@snowman.net>)
Re: A better way than tweaking NTUP_PER_BUCKET  (Jeff Janes <jeff.janes@gmail.com>)
Список pgsql-hackers
On 23 June 2013 03:16, Stephen Frost <sfrost@snowman.net> wrote:

> Will think on it more.

Some other thoughts related to this...

* Why are we building a special kind of hash table? Why don't we just
use the hash table code that we in every other place in the backend.
If that code is so bad why do we use it everywhere else? That is
extensible, so we could try just using that. (Has anyone actually
tried?)

* We're not thinking about cache locality and set correspondence
either. If the join is expected to hardly ever match, then we should
be using a bitmap as a bloom filter rather than assuming that a very
large hash table is easily accessible.

* The skew hash table will be hit frequently and would show good L2
cache usage. I think I'll try adding the skew table always to see if
that improves the speed of the hash join.

-- Simon Riggs                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services



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

Предыдущее
От: Ian Link
Дата:
Сообщение: Re: Patch for fast gin cache performance improvement
Следующее
От: Rok Kralj
Дата:
Сообщение: INTERVAL overflow detection is terribly broken