On Tue, Sep 9, 2008 at 7:48 AM, Kenneth Marshall <[EMAIL PROTECTED]> 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... :)

Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:

Reply via email to