Skip site navigation (1) Skip section navigation (2)

Re: Optimizing pg_trgm makesign() (was Re: WIP: Fast GiST index build)

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Optimizing pg_trgm makesign() (was Re: WIP: Fast GiST index build)
Date: 2011-09-25 22:30:18
Message-ID: (view raw or whole thread)
Lists: pgsql-hackers
This is a review of the patch at this CF location:
as posted here:
This patch applied cleanly and compiled without warning.  It
performed correctly.  Since the patch modifies one function which has
one input and one output (through a pointer parameter), with no other
side effects, it has low risk of surprising problems.
It is strictly a performance patch, and accomplishes its goals.  I
ran the entire dictionary through the patched and unpatched versions
five times each (using the supplied debugging patch) and saw no
changes to the behavior of the function -- identical results every
time.  I ran performance tests with building and reindexing the
sorted dictionary, a randomly ordered dictionary, a randomly ordered
dictionary with the entries randomly truncated to 0 to 3 characters,
and a large README file -- five times each with and without the
patch.  The patch was a clear winner with all of those except the
truncated dictionary, where the difference we well within the noise
(0.05% difference summing five runs when individual runs could vary
by up to about 4%).
While there was no reason to believe it could affect search
performance, I tested that anyway, and found no difference.
Once this message shows up on the list (so I can retrieve the message
ID) I will mark this "Ready for Committer".


pgsql-hackers by date

Next:From: Robert HaasDate: 2011-09-26 00:46:22
Subject: Re: index-only scans
Previous:From: Bruce MomjianDate: 2011-09-25 21:12:34
Subject: Re: fix for pg_upgrade

Privacy Policy | About PostgreSQL
Copyright © 1996-2015 The PostgreSQL Global Development Group