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
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,
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
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
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
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
* 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
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
