From: | Grzegorz Jaskiewicz <gj(at)pointblue(dot)com(dot)pl> |
---|---|
To: | "Luke Lonergan" <LLonergan(at)greenplum(dot)com> |
Cc: | "Joshua D(dot)Drake" <jd(at)commandprompt(dot)com>, "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>, "PostgreSQL-development Hackers" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCHES] Bitmapscan changes |
Date: | 2007-03-18 00:44:33 |
Message-ID: | 8981D951-79C0-40E5-BCD0-4F777820DE9A@pointblue.com.pl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mar 17, 2007, at 10:33 PM, Luke Lonergan wrote:
> Wow, nice!
>
> Can you tell us:
> - how big is the table
> - cardinality of the column
> - how big is the index in each case
> - how much memory on the machine
> - query and explain analyze
>
All I changed, was the 400k to 150k
512MB of ram, as I said earlier. And it is running 64bit kernel,
32bit user-land on linux 2.6.20
query and explain is going to run for a while, so I'll leave it - as
it is going to be the same on other machines (much faster ones).
postgres=# select pg_size_pretty( pg_relation_size
( 'narrowtable_index' ) );
pg_size_pretty
----------------
321 MB
(1 row)
postgres=# select pg_size_pretty( pg_relation_size
( 'narrowtable2_clustered_index' ) );
pg_size_pretty
----------------
3960 kB
(1 row)
(so there's quite a difference).
Judging from noises coming out of machine, there was pretty loads of
I/O activity. and funny enough, one CPU was stucked on 'wait' up to
80% most of the time.
the 'cardinality', as I guess, uniqueness is the same as intended in
original test. Like I said, only table size was changed.
select count(distinct key) from narrowtable; and select count(*) from
narrowtable; are the same - 15000000
hth.
--
Grzegorz Jaskiewicz
C/C++ freelance for hire
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2007-03-18 04:03:58 | Re: Bug in UTF8-Validation Code? |
Previous Message | Andrew Dunstan | 2007-03-17 23:09:07 | Re: Bug in UTF8-Validation Code? |