> What first post? The only thing I can find is a reference in a message
> by you from yesterday, to a two-year old post that you claim is about
> the same problem. Though it's possible that it is the same problem,
> you don't provide any data to back that up.
Strange - you can see the full
> postgres collect all necessary stats. Maybe an implicit analyze is
> necessary?
Should be: "explicit analyze".
> > > BUT I found the real cause of my problem - the "fk2" field from my
> > > example had not only an index, but it was also a foreign key to
> > > another table.
> > That seems unlik
Alban Hertroys wrote:
> On 25 Jul 2009, at 11:36, MS wrote:
>
>>> can we see an explain analyze at least?
>>>
>>
>> Hi,
>> Well, it won't be necessary - I mean it looks just like the explain I
>> sent in my first post.
>
> What first post? The only thing I can find is a reference in a message
> by
On Sat, Jul 25, 2009 at 8:45 AM, Sam Mason wrote:
> On Sat, Jul 25, 2009 at 02:36:19AM -0700, MS wrote:
>> I believe the update took so long because pgsql was checking if the
>> changes don't break the referential integrity.
>> So - problem solved, postgres good. ;) But isn't there a way to make
>>
On Sat, Jul 25, 2009 at 02:36:19AM -0700, MS wrote:
> I believe the update took so long because pgsql was checking if the
> changes don't break the referential integrity.
> So - problem solved, postgres good. ;) But isn't there a way to make
> some bulk operations without having to drop indexes/FKs
On 25 Jul 2009, at 11:36, MS wrote:
can we see an explain analyze at least?
Hi,
Well, it won't be necessary - I mean it looks just like the explain I
sent in my first post.
What first post? The only thing I can find is a reference in a message
by you from yesterday, to a two-year old post
> can we see an explain analyze at least?
>
Hi,
Well, it won't be necessary - I mean it looks just like the explain I
sent in my first post.
BUT I found the real cause of my problem - the "fk2" field from my
example had not only an index, but it was also a foreign key to
another table.
I believe t
On Fri, Jul 24, 2009 at 4:40 PM, MS wrote:
>
>> I never cease to be amazed at how many times people have these monster
>> CPUs, like dual quad core 3Ghz processors, with 16GB or whatever of ram,
>> and then try and run a database off a single 7200 rpm desktop SATA
>> drive. at work our productio
> I never cease to be amazed at how many times people have these monster
> CPUs, like dual quad core 3Ghz processors, with 16GB or whatever of ram,
> and then try and run a database off a single 7200 rpm desktop SATA
> drive. at work our production databases often run on dozens of 1
> or 15
MS wrote:
Btw. It looks like this issue:
http://archives.postgresql.org/pgsql-performance/2007-09/msg00374.php
In my case the CPU usage is low too (3%) but IO wait is high (95%).
I'm using Postgresql 8.3.
for more info on disk iowaits, use `iostat -x 5` (5 means sample every
5 seconds),
Btw. It looks like this issue:
http://archives.postgresql.org/pgsql-performance/2007-09/msg00374.php
In my case the CPU usage is low too (3%) but IO wait is high (95%).
I'm using Postgresql 8.3.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subsc
11 matches
Mail list logo
