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

Re: hash index improving v3

From: "Alex Hunsaker" <badalex(at)gmail(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Zdenek Kotala" <Zdenek(dot)Kotala(at)sun(dot)com>, "Xiao Meng" <mx(dot)cogito(at)gmail(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-05 06:32:16
Message-ID: 34d269d40809042332l7a1ac5e9t8b1dded2b951dcd2@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
On Thu, Sep 4, 2008 at 9:48 PM, Alex Hunsaker <badalex(at)gmail(dot)com> wrote:

Ok here are the results:

(data generated from the c program before)
select count(1) from test_hash;
   count
-----------
 100000011

create index test_hash_num_idx on test_hash using hash (num);
CVS: Time: 698065.180 ms
patch: Time: 565982.099 ms

./pgbench -c 1 -t 100000 -n -f bench.sql
bench.sql
select count(1) from test_hash where num = 110034304728896610;

CVS: tps = 7232.375875 (excluding connections establishing)
patch: tps = 7913.700150 (excluding connections establishing)

EXPLAIN ANALYZE select count(1) from test_hash where num = 110034304728896610;
                                                             QUERY
PLAN
------------------------------------------------------------------------------------------------------------------------------------
 Aggregate  (cost=29.24..29.25 rows=1 width=0) (actual
time=0.066..0.067 rows=1 loops=1)
   ->  Index Scan using test_hash_num_idx on test_hash
(cost=0.00..29.24 rows=1 width=0) (actual time=0.051..0.054 rows=1
loops=1)
         Index Cond: (num = 110034304728896610::bigint)
 Total runtime: 0.153 ms


Oddly the index sizes were the same (4096 MB) is that to be expected?

Here is the change I made to hashint8
--- a/src/backend/access/hash/hashfunc.c
+++ b/src/backend/access/hash/hashfunc.c
@@ -61,12 +61,14 @@ hashint8(PG_FUNCTION_ARGS)
         */
 #ifndef INT64_IS_BUSTED
        int64           val = PG_GETARG_INT64(0);
-       uint32          lohalf = (uint32) val;
+/*     uint32          lohalf = (uint32) val;
        uint32          hihalf = (uint32) (val >> 32);

        lohalf ^= (val >= 0) ? hihalf : ~hihalf;

        return hash_uint32(lohalf);
+*/
+       return val % 4294967296;
 #else
        /* here if we can't count on "x >> 32" to work sanely */
        return hash_uint32((int32) PG_GETARG_INT64(0));

In response to

Responses

pgsql-hackers by date

Next:From: Zdenek KotalaDate: 2008-09-05 06:43:14
Subject: Re: hash index improving v3
Previous:From: Volkan YAZICIDate: 2008-09-05 06:20:52
Subject: Re: Verbosity of Function Return Type Checks

pgsql-patches by date

Next:From: Zdenek KotalaDate: 2008-09-05 06:43:14
Subject: Re: hash index improving v3
Previous:From: Alex HunsakerDate: 2008-09-05 03:48:41
Subject: Re: hash index improving v3

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