Re: [PERFORM] How to turn autovacuum prevent wrap around run faster?

2011-01-12 Thread marc.hsiao
Hi All: My Server list below postgres=# select version(); version --- PostgreSQL 8.4.2 on x86_64-unknown-linux-gnu, compiled by

[PERFORM] Slow query + why bitmap index scan??

2011-01-12 Thread Laszlo Nagy
This will be simple question to answer. :-) There is a single table: select count(*) from product_price_history -- 12982555 rows This table has exactly one index and on primary key constraint: CREATE INDEX idx_product_price_history_id_hdate ON product_price_history USING btree (id, hdat

Re: [PERFORM] Slow query + why bitmap index scan??

2011-01-12 Thread Florian Weimer
* Laszlo Nagy: > This query: > > select hid from product_price_history where id=35547581 > > Returns 759 rows in 8837 msec! How can this be that slow??? If most records are on different heap pages, processing this query requires many seeks. 11ms per seek is not too bad if most of them are cache

[PERFORM] The good, old times

2011-01-12 Thread Mladen Gogala
I am running a postgres update on one of my machines: Downloading Packages: (1/7): postgresql90-plpython-9.0.2-2PGDG.rhel5.x86_64.rp | 50 kB 00:02 (2/7): postgresql90-plperl-9.0.2-2PGDG.rhel5.x86_64.rpm | 51 kB 00:03 (3/7): postgresql90-libs-9.0.2-2PGDG.rhel5.x86_64.rpm

Re: [PERFORM] The good, old times

2011-01-12 Thread Guillaume Cottenceau
Mladen Gogala writes: > I am running a postgres update on one of my machines: > > Downloading Packages: > (1/7): postgresql90-plpython-9.0.2-2PGDG.rhel5.x86_64.rp | 50 kB > 00:02 (2/7): postgresql90-plperl-9.0.2-2PGDG.rhel5.x86_64.rpm | > 51 kB 00:03 (3/7): > postgresql90-libs-9.0.2

Re: [PERFORM] Slow query + why bitmap index scan??

2011-01-12 Thread Laszlo Nagy
On 2011-01-12 14:42, Florian Weimer wrote: * Laszlo Nagy: This query: select hid from product_price_history where id=35547581 Returns 759 rows in 8837 msec! How can this be that slow??? If most records are on different heap pages, processing this query requires many seeks. 11ms per seek is

Re: [PERFORM] Slow query + why bitmap index scan??

2011-01-12 Thread Kenneth Marshall
On Wed, Jan 12, 2011 at 03:21:45PM +0100, Laszlo Nagy wrote: > On 2011-01-12 14:42, Florian Weimer wrote: >> * Laszlo Nagy: >> >>> This query: >>> >>> select hid from product_price_history where id=35547581 >>> >>> Returns 759 rows in 8837 msec! How can this be that slow??? >> If most records are o

Re: [PERFORM] Slow query + why bitmap index scan??

2011-01-12 Thread Kevin Grittner
Laszlo Nagy wrote: > shared_mem = 6GB > work_mem = 512MB > total system memory=24GB In addition to the good advice from Ken, I suggest that you set effective_cache_size (if you haven't already). Add whatever the OS shows as RAM used for cache to the shared_mem setting. But yeah, for your im

Re: [PERFORM] Slow query + why bitmap index scan??

2011-01-12 Thread Laszlo Nagy
On 2011-01-12 15:36, Kevin Grittner wrote: Laszlo Nagy wrote: shared_mem = 6GB work_mem = 512MB total system memory=24GB In addition to the good advice from Ken, I suggest that you set effective_cache_size (if you haven't already). Add whatever the OS shows as RAM used for cache to the shar

Re: [PERFORM] Slow query + why bitmap index scan??

2011-01-12 Thread Kevin Grittner
Laszlo Nagy wrote: >> In addition to the good advice from Ken, I suggest that you set >> effective_cache_size (if you haven't already). Add whatever the >> OS shows as RAM used for cache to the shared_mem setting. > It was 1GB. Now I changed to 2GB. Although the OS shows 9GB > inactive memory,

Re: [PERFORM] Performance test of Oracle and PostgreSQL using same binary

2011-01-12 Thread Jeff Janes
On Tue, Jan 11, 2011 at 10:54 PM, Divakar Singh wrote: > Hello all, > I am trying to do comparative study of PostgreSQL and Oracle. > Has anybody tried to use same binary for connecting to oracle as well as > PostgreSQL at the same time? > I mean the program should be able to create 1 connection t

Re: [PERFORM] Slow query + why bitmap index scan??

2011-01-12 Thread Cédric Villemain
2011/1/12 Kevin Grittner : > Laszlo Nagy wrote: > >>>  In addition to the good advice from Ken, I suggest that you set >>> effective_cache_size (if you haven't already).  Add whatever the >>> OS shows as RAM used for cache to the shared_mem setting. >> It was 1GB. Now I changed to 2GB. Although th