Re: [POC] A better way to expand hash indexes.

From: Mithun Cy <mithun(dot)cy(at)enterprisedb(dot)com>
To: David Steele <david(at)pgmasters(dot)net>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [POC] A better way to expand hash indexes.
Date: 2017-03-18 17:29:21
Message-ID: CAD__OuiWzFB7vdasUhBJwLGxG_aSrsjxb3UfV8x7qOOWCGJ-0g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Mar 16, 2017 at 10:55 PM, David Steele <david(at)pgmasters(dot)net> wrote:
> It does apply with fuzz on 2b32ac2, so it looks like c11453c and
> subsequent commits are the cause. They represent a fairly substantial
> change to hash indexes by introducing WAL logging so I think you should
> reevaluate your patches to be sure they still function as expected.

Thanks, David here is the new improved patch I have also corrected the
pageinspect's test output. Also, added notes in README regarding the
new way of adding bucket pages efficiently in hash index. I also did
some more tests pgbench read only and read write;
There is no performance impact due to the patch. The growth of index
size has become much efficient as the numbers posted in the initial
proposal mail.

--
Thanks and Regards
Mithun C Y
EnterpriseDB: http://www.enterprisedb.com

Attachment Content-Type Size
expand_hashbucket_efficiently_03.patch application/octet-stream 18.3 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2017-03-18 17:32:06 Re: New CORRESPONDING clause design
Previous Message Rushabh Lathia 2017-03-18 17:22:43 Re: wait events for disk I/O