Re: hash index improving v3

From: Kenneth Marshall <ktm(at)rice(dot)edu>
To: Alex Hunsaker <badalex(at)gmail(dot)com>
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-12 14:29:21
Message-ID: 20080912142921.GB26773@it.is.rice.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

On Thu, Sep 11, 2008 at 08:51:53PM -0600, Alex Hunsaker wrote:
> On Thu, Sep 11, 2008 at 9:24 AM, Kenneth Marshall <ktm(at)rice(dot)edu> 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
> > this:
> >
> > for ($coll=500; $i<=1000000; $i=$i*2) {
> > for ($i=0; $i<=1000000; $i++) {
> > hash(int8 $i);
> > }
> > # add the appropriate number of collisions, distributed evenly to
> > # minimize the packing overrun problem
> > for ($dup=0; $dup<=$coll; $dup++) {
> > hash(int8 MAX_INT + $dup * 1000000/$coll);
> > }
> > }
> >
> > Ken
>
> *doh* right something like this...
>
> create or replace function create_test_hash() returns bool as $$
> declare
> coll integer default 500;
> -- tweak this to where create index gets really slow
> max_coll integer default 1000000;
> begin
> loop
> execute 'create table test_hash_'|| coll ||'(num int8);';
> execute 'insert into test_hash_'|| coll ||' (num) select n
> from generate_series(0, '|| max_coll ||') as n;';
> execute 'insert into test_hash_'|| coll ||' (num) select
> (n+4294967296) * '|| max_col ||'/'|| coll ||'::int from
> generate_series(0, '|| coll ||') as n;';
>
> coll := coll * 2;
>
> exit when coll >= max_coll;
> end loop;
> return true;
> end;
> $$ language 'plpgsql';
>
> And then benchmark each table, and for extra credit cluster the table
> on the index and benchmark that.
>
> Also obviously with the hashint8 which just ignores the top 32 bits.
>
> Right?
>
Yes, that is exactly right.

Ken

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message D'Arcy J.M. Cain 2008-09-12 14:33:43 Re: Parsing of pg_hba.conf and authentication inconsistencies
Previous Message Hannu Krosing 2008-09-12 14:24:29 Re: Synchronous Log Shipping Replication

Browse pgsql-patches by date

  From Date Subject
Next Message Alex Hunsaker 2008-09-12 16:32:57 Re: hash index improving v3
Previous Message Zdenek Kotala 2008-09-12 09:14:58 Re: hash index improving v3