On 09/13/2016 07:26 AM, Amit Kapila wrote:
Attached, new version of patch which contains the fix for problem
reported on write-ahead-log of hash index thread [1].
I have been testing patch in various scenarios, and it has a positive
performance impact in some cases.
This is especially seen in cases where the values of the indexed column
are unique - SELECTs can see a 40-60% benefit over a similar query using
b-tree. UPDATE also sees an improvement.
In cases where the indexed column value isn't unique, it takes a long
time to build the index due to the overflow page creation.
Also in cases where the index column is updated with a high number of
clients, ala
-- ddl.sql --
CREATE TABLE test AS SELECT generate_series(1, 10) AS id, 0 AS val;
CREATE INDEX IF NOT EXISTS idx_id ON test USING hash (id);
CREATE INDEX IF NOT EXISTS idx_val ON test USING hash (val);
ANALYZE;
-- test.sql --
\set id random(1,10)
\set val random(0,10)
BEGIN;
UPDATE test SET val = :val WHERE id = :id;
COMMIT;
w/ 100 clients - it takes longer than the b-tree counterpart (2921 tps
for hash, and 10062 tps for b-tree).
Jeff mentioned upthread the idea of moving the lock to a bucket meta
page instead of having it on the main meta page. Likely a question for
the assigned committer.
Thanks for working on this !
Best regards,
Jesper
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
