Re: [PATCHES] Bitmapscan changes - Mailing list pgsql-hackers

From Grzegorz Jaskiewicz
Subject Re: [PATCHES] Bitmapscan changes
Date
Msg-id 8981D951-79C0-40E5-BCD0-4F777820DE9A@pointblue.com.pl
Whole thread Raw
In response to Re: [PATCHES] Bitmapscan changes  ("Luke Lonergan" <LLonergan@greenplum.com>)
List 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







pgsql-hackers by date:

Previous
From: "Luke Lonergan"
Date:
Subject: Re: [PATCHES] Bitmapscan changes
Next
From: Andrew Dunstan
Date:
Subject: Re: Bug in UTF8-Validation Code?