On Mon, Oct 12, 2009 at 5:23 AM, Michal Vitecek wrote:
> Merlin Moncure wrote:
>>On Tue, Oct 6, 2009 at 10:59 AM, Michal Vitecek wrote:
>>> Merlin Moncure wrote:
On Mon, Oct 5, 2009 at 5:17 AM, Michal Vitecek wrote:
> Could the problem be the HW RAID card? There's ServerRAID 8k wit
Merlin Moncure wrote:
>On Tue, Oct 6, 2009 at 10:59 AM, Michal Vitecek wrote:
>> Merlin Moncure wrote:
>>>On Mon, Oct 5, 2009 at 5:17 AM, Michal Vitecek wrote:
>>>
Could the problem be the HW RAID card? There's ServerRAID 8k with 256MB
with write-back enabled. Could it be that its int
Merlin Moncure wrote:
On Tue, Oct 6, 2009 at 10:59 AM, Michal Vitecek wrote:
Merlin Moncure wrote:
On Mon, Oct 5, 2009 at 5:17 AM, Michal Vitecek wrote:
Could the problem be the HW RAID card? There's ServerRAID 8k with 256MB
with write-back enabled. Could it be that its internal cache bec
On Tue, Oct 6, 2009 at 10:59 AM, Michal Vitecek wrote:
> Merlin Moncure wrote:
>>On Mon, Oct 5, 2009 at 5:17 AM, Michal Vitecek wrote:
>>
>>> Could the problem be the HW RAID card? There's ServerRAID 8k with 256MB
>>> with write-back enabled. Could it be that its internal cache becomes
>>> ful
Merlin Moncure wrote:
>On Mon, Oct 5, 2009 at 5:17 AM, Michal Vitecek wrote:
>
>> Could the problem be the HW RAID card? There's ServerRAID 8k with 256MB
>> with write-back enabled. Could it be that its internal cache becomes
>> full and all disk I/O operations are delayed until it writes all
>
On Mon, Oct 5, 2009 at 5:17 AM, Michal Vitecek wrote:
> Could the problem be the HW RAID card? There's ServerRAID 8k with 256MB
> with write-back enabled. Could it be that its internal cache becomes
> full and all disk I/O operations are delayed until it writes all
> changes to hard drives?
Robert Haas wrote:
>On Fri, Oct 2, 2009 at 9:54 AM, Merlin Moncure wrote:
>> On Fri, Oct 2, 2009 at 4:18 AM, Michal Vitecek wrote:
>>> Hello everyone,
>>>
>>> I'm using PostgreSQL 8.3.8 running on a server with 2 Xeon CPUs, 4GB
>>> RAM, 4+2 disks in RAID 5 and CentOS 5.3. There's only one data
Robert Haas wrote:
> On Fri, Oct 2, 2009 at 9:54 AM, Merlin Moncure wrote:
>> On Fri, Oct 2, 2009 at 4:18 AM, Michal Vitecek wrote:
>>> Hello everyone,
>>>
>>> I'm using PostgreSQL 8.3.8 running on a server with 2 Xeon CPUs, 4GB
>>> RAM, 4+2 disks in RAID 5 and CentOS 5.3. There's only one dat
On Fri, Oct 2, 2009 at 1:39 PM, Robert Haas wrote:
> On Fri, Oct 2, 2009 at 9:54 AM, Merlin Moncure wrote:
>> it is ridiculous. your problem is almost definitely dead rows. I
>> can't recall (and I can't find the info anywhere) if the 'hot' feature
>> requires an index to be active -- I think i
On Fri, Oct 2, 2009 at 9:54 AM, Merlin Moncure wrote:
> On Fri, Oct 2, 2009 at 4:18 AM, Michal Vitecek wrote:
>> Hello everyone,
>>
>> I'm using PostgreSQL 8.3.8 running on a server with 2 Xeon CPUs, 4GB
>> RAM, 4+2 disks in RAID 5 and CentOS 5.3. There's only one database
>> which dumped wit
On Fri, Oct 2, 2009 at 4:18 AM, Michal Vitecek wrote:
> Hello everyone,
>
> I'm using PostgreSQL 8.3.8 running on a server with 2 Xeon CPUs, 4GB
> RAM, 4+2 disks in RAID 5 and CentOS 5.3. There's only one database
> which dumped with pgdump takes ~0.5GB.
>
> There are ~100 tables in the datab
There are ~100 tables in the database and one of them (tableOne) always
contains only a single row. There's one index on it. However performing
update on the single row (which occurs every 60 secs) takes a
considerably long time -- around 200ms. The system is not loaded in any
way.
How often is
In response to Michal Vitecek :
> There are ~100 tables in the database and one of them (tableOne) always
> contains only a single row. There's one index on it. However performing
In this case, only one row, you don't need an index. Really.
> update on the single row (which occurs every 60 sec
Hello everyone,
I'm using PostgreSQL 8.3.8 running on a server with 2 Xeon CPUs, 4GB
RAM, 4+2 disks in RAID 5 and CentOS 5.3. There's only one database
which dumped with pgdump takes ~0.5GB.
There are ~100 tables in the database and one of them (tableOne) always
contains only a single row.
14 matches
Mail list logo