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

Re: hash index improving v3

From: "Alex Hunsaker" <badalex(at)gmail(dot)com>
To: "Kenneth Marshall" <ktm(at)rice(dot)edu>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Xiao Meng" <mx(dot)cogito(at)gmail(dot)com>, "Zdenek Kotala" <Zdenek(dot)Kotala(at)sun(dot)com>, pgsql-patches(at)postgresql(dot)org, "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>
Subject: Re: hash index improving v3
Date: 2008-09-10 01:23:03
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
On Tue, Sep 9, 2008 at 7:48 AM, Kenneth Marshall <ktm(at)rice(dot)edu> wrote:
> I think that the glacial speed for generating a big hash index is
> the same problem that the original code faced.

Yeah sorry, I was not saying it was a new problem with the patch.  Err
at least not trying to :) *Both* of them had been running at 18+ (I
finally killed them sometime Sunday or around +32 hours...)

> It would be useful to have an equivalent test for the hash-only
> index without the modified int8 hash function, since that would
> be more representative of its performance. The collision rates
> that I was observing in my tests of the old and new mix() functions
> was about 2 * (1/10000) of what you test generated. You could just
> test against the integers between 1 and 2000000.

Sure but then its pretty much just a general test of patch vs no
patch.  i.e. How do we measure how much longer collisions take when
the new patch makes things faster?  That's what I was trying to
measure... Though I apologize I don't think that was clearly stated
Now of course it still would be interesting...  And if its only to
2,000,000 I can still use the modified int8 or just use the int4

Anyway Here are the numbers:
create table test_hash(num int8);
insert into test_hash (num) select generate_series(1, 2000000);
create index test_hash_num_idx on test_hash (num);

pgbench -c1 -n -t10000 -f bench_index.sql
cvs head: tps = 3161.500511
v5:           tps = 7248.808839

BTW Im still planning on doing a wide vs narrow test... sometime... :)

In response to


pgsql-hackers by date

Next:From: Alex HunsakerDate: 2008-09-10 01:27:14
Subject: Re: [PATCHES] to_date() validation
Previous:From: Tom LaneDate: 2008-09-10 00:28:48
Subject: Re: [PATCH] Cleanup of GUC units code

pgsql-patches by date

Next:From: Alex HunsakerDate: 2008-09-10 01:27:14
Subject: Re: [PATCHES] to_date() validation
Previous:From: Ryan BradetichDate: 2008-09-09 15:14:59
Subject: Re: [PgFoundry] Unsigned Data Types [1 of 2]

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