Re: [PATCHES] Bitmapscan changes
От | Grzegorz Jaskiewicz |
---|---|
Тема | Re: [PATCHES] Bitmapscan changes |
Дата | |
Msg-id | 8981D951-79C0-40E5-BCD0-4F777820DE9A@pointblue.com.pl обсуждение исходный текст |
Ответ на | Re: [PATCHES] Bitmapscan changes ("Luke Lonergan" <LLonergan@greenplum.com>) |
Список | 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 по дате отправления: