Re: hash index improving v3

Поиск
Список
Период
Сортировка
От Alex Hunsaker
Тема Re: hash index improving v3
Дата
Msg-id 34d269d40809042048m3b532a5ej7a9588f63a788d0c@mail.gmail.com
обсуждение исходный текст
Ответ на Re: hash index improving v3  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: hash index improving v3  ("Alex Hunsaker" <badalex@gmail.com>)
Re: hash index improving v3  ("Alex Hunsaker" <badalex@gmail.com>)
Список pgsql-patches
On Thu, Sep 4, 2008 at 8:17 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I guess one thing we could do for testing purposes is lobotomize one of
> the datatype-specific hash functions.  For instance, make int8_hash
> return the input mod 2^32, ignoring the upper bytes.  Then it'd be easy
> to compute different int8s that hash to the same thing.


Heh Ok im slowly getting there... So we lobotomize hashint8 and then
time how long it takes to make an index on a table... something like:
create table test_hash(num int8);

(obviously on a 64 bit machine)
int main(void)
{
    unsigned long y = 0;
    unsigned cnt = 0;

    printf("insert into test_hash (num) values ");

    //while(cnt != LONG_MAX/UINT_MAX)
    while(cnt < 10000000)
    {
        y += UINT_MAX;

        printf("(%ld), ", y);

        cnt++;
    }

    printf("(0);\n");

}

./a.out | psql

pgbench -c 1 -t1000 -n -f test.sql

test.sql:
create index test_hash_num_idx on test_hash using hash (num);
drop index test_hash_num_idx;

For both pre and post patch just to make sure post patch is not worse
than pre patch???

If im still way off and its not to much trouble want to give me a test
case to run =) ?

Or maybe because hash collisions should be fairly rare its not
something to really worry about?

В списке pgsql-patches по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: hash index improving v3
Следующее
От: "Alex Hunsaker"
Дата:
Сообщение: Re: hash index improving v3