Re: [HACKERS] pgsql 10: hash indexes testing

Поиск
Список
Период
Сортировка
От AP
Тема Re: [HACKERS] pgsql 10: hash indexes testing
Дата
Msg-id 20170810233151.vvph2h7rwceyzf7r@zip.com.au
обсуждение исходный текст
Ответ на Re: [HACKERS] pgsql 10: hash indexes testing  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: [HACKERS] pgsql 10: hash indexes testing  (Amit Kapila <amit.kapila16@gmail.com>)
Список pgsql-hackers
On Thu, Aug 10, 2017 at 01:12:25PM -0400, Robert Haas wrote:
> On Thu, Aug 10, 2017 at 6:41 AM, AP <ap@zip.com.au> wrote:
> > The index is 135GB rather than 900GB (from memory/give or take).
> 
> Whoa.  Big improvement.

Not a good direct comparison in general but it fits my workload.

The 900GB was fillfactor 10 and the 135 was ff 90 BUT ff 90 on
v3 fails early into the import. Even ff 10 on v3 didn't succeed (came just
short). So for my usage I was facing having indexes with fillfactor 10
just to be able to put a more reasonable amount of data in them. Almost.

Now I don't have to as v4 copes with the load and more and in less disk
space so for me, the above is just lovely. :) This is even more so
given that the hash index v4 upload actually finished unlike the v3 one. :)

As I said in my last email, this weekend I'll be adding more to that table
so I'll see how far that takes me but the last two patches have given
me a great deal of confidence that the end result will be good news. :)

As an aside, btree for the above is around 2.5x bigger than hash v4 so 
chances are much better that a hash index will fit into ram which has
its own benefits. :)

AP



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

Предыдущее
От: Thomas Munro
Дата:
Сообщение: Re: [HACKERS] Thoughts on unit testing?
Следующее
От: Thomas Munro
Дата:
Сообщение: Re: [HACKERS] Thoughts on unit testing?