On Thu, Sep 11, 2008 at 08:51:53PM -0600, Alex Hunsaker wrote:
On Thu, Sep 11, 2008 at 9:24 AM, Kenneth Marshall [EMAIL PROTECTED] wrote:
Alex,
I meant to check the performance with increasing numbers of collisions,
not increasing size of the hashed item. In other words, something like
On Wed, Sep 10, 2008 at 10:17:31PM -0600, Alex Hunsaker wrote:
On Wed, Sep 10, 2008 at 9:49 PM, Alex Hunsaker [EMAIL PROTECTED] wrote:
On Wed, Sep 10, 2008 at 7:04 AM, Kenneth Marshall [EMAIL PROTECTED] wrote:
On Tue, Sep 09, 2008 at 07:23:03PM -0600, Alex Hunsaker wrote:
On Tue, Sep 9
On Sat, Sep 06, 2008 at 08:23:05PM -0600, Alex Hunsaker wrote:
On Sat, Sep 6, 2008 at 1:09 PM, Tom Lane [EMAIL PROTECTED] wrote:
For the convenience of anyone intending to test, here is an updated
patch against CVS HEAD that incorporates Alex's fix.
Here are the results for a table
On Sun, Oct 28, 2007 at 08:06:58PM +, Simon Riggs wrote:
On Sun, 2007-10-28 at 13:05 -0500, Kenneth Marshall wrote:
On Sun, Oct 28, 2007 at 05:27:38PM +, Simon Riggs wrote:
On Sat, 2007-10-27 at 15:15 -0500, Kenneth Marshall wrote:
Its features include a better and faster hash
On Sun, Apr 06, 2008 at 12:02:25PM -0400, Tom Lane wrote:
Kenneth Marshall [EMAIL PROTECTED] writes:
Okay, I will strip the VALGRIND paths. I did not see a real need for them
either.
I have a patch ready to commit (as soon as I fix the regression test
issues) that incorporates all
On Sat, Apr 05, 2008 at 03:40:35PM -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Sun, 2007-10-28 at 13:05 -0500, Kenneth Marshall wrote:
The new hash function is roughly twice as fast as the old function in
terms of straight CPU time. It uses the same design as the current
On Wed, Mar 19, 2008 at 10:51:12AM +0100, Martijn van Oosterhout wrote:
On Wed, Mar 19, 2008 at 09:38:12AM +0100, Peter Eisentraut wrote:
Another factor I just thought of is that tar, commonly used as part of a
backup procedure, can on some systems only handle files up to 8 GB in size.
On Sun, Mar 16, 2008 at 10:53:02PM -0400, Tom Lane wrote:
Kenneth Marshall [EMAIL PROTECTED] writes:
Dear PostgreSQL Developers,
This patch is a diff -c against the hashfunc.c from postgresql-8.3beta1.
It's pretty obvious that this patch hasn't even been tested on a
big-endian machine
On Fri, Nov 16, 2007 at 01:19:13AM -0800, Alex Vinokur wrote:
On Nov 15, 1:23 pm, [EMAIL PROTECTED] (Heikki Linnakangas)
wrote:
Alex Vinokurwrote:
On Nov 15, 10:40 am,Alex Vinokur[EMAIL PROTECTED]
wrote:
[snip]
I have some question concerning Bob Jenkins' functions
On Sun, Oct 28, 2007 at 05:27:38PM +, Simon Riggs wrote:
On Sat, 2007-10-27 at 15:15 -0500, Kenneth Marshall wrote:
Its features include a better and faster hash function.
Looks very promising. Do you have any performance test results to show
it really is faster, when compiled
On Sun, Oct 28, 2007 at 08:06:58PM +, Simon Riggs wrote:
On Sun, 2007-10-28 at 13:05 -0500, Kenneth Marshall wrote:
On Sun, Oct 28, 2007 at 05:27:38PM +, Simon Riggs wrote:
On Sat, 2007-10-27 at 15:15 -0500, Kenneth Marshall wrote:
Its features include a better and faster hash
Dear PostgreSQL Developers,
This patch is a diff -c against the hashfunc.c from postgresql-8.3beta1.
It implements the 2006 version of the hash function by Bob Jenkins. Its
features include a better and faster hash function. I have included the
versions supporting big-endian and little-endian
On Wed, Apr 25, 2007 at 10:00:16AM +0200, Zeugswetter Andreas ADI SD wrote:
1) To deal with partial/inconsisitent write to the data file at
crash
recovery, we need full page writes at the first modification to
pages
after each checkpoint. It consumes much of WAL space.
We need
13 matches
Mail list logo
