Steve Crawford wrote:
> Greg Smith wrote:
>> Jochen Erwied wrote:
>>> - Promise Technology Supertrak ES4650 + additional BBU
>>>
>> I've never seen a Promise controller that had a Linux driver you would
>> want to rely on under any circumstances...
> +1
>
> I haven't tried Promise recently, but
On Thursday 26 November 2009 17:20:35 Richard Neill wrote:
> Dear All,
>
> I'm wondering whether Vacuum/analyse (notably by the autovaccuum daemon)
> is responsible for some deadlocks/dropouts I'm seeing.
>
> One particular table gets hit about 5 times a second (for single row
> updates and inser
Richard Neill writes:
> I'm wondering whether Vacuum/analyse (notably by the autovaccuum daemon)
> is responsible for some deadlocks/dropouts I'm seeing.
> One particular table gets hit about 5 times a second (for single row
> updates and inserts) + associated index changes. This is a very ligh
On Thu, Nov 26, 2009 at 4:20 PM, Richard Neill wrote:
> Dear All,
>
> I'm wondering whether Vacuum/analyse (notably by the autovaccuum daemon) is
> responsible for some deadlocks/dropouts I'm seeing.
>
> One particular table gets hit about 5 times a second (for single row
> updates and inserts) +
Dear All,
I'm wondering whether Vacuum/analyse (notably by the autovaccuum daemon)
is responsible for some deadlocks/dropouts I'm seeing.
One particular table gets hit about 5 times a second (for single row
updates and inserts) + associated index changes. This is a very light
load for the ha
Sergey Aleynikov wrote:
Hello,
2009/11/25 Richard Neill :
Also, if you find odd statistics of freshly analyzed table - try
increasing statistics target, using
ALTER TABLE .. ALTER COLUMN .. SET STATISTICS ...
If you're using defaults - it's again low for large tables. Start with
200, for exa
Hello,
2009/11/25 Richard Neill :
Also, if you find odd statistics of freshly analyzed table - try
increasing statistics target, using
ALTER TABLE .. ALTER COLUMN .. SET STATISTICS ...
If you're using defaults - it's again low for large tables. Start with
200, for example.
Best regards,
Sergey
Hello,
2009/11/25 Richard Neill :
>It's a simple query, but using a complex view. So I can't really re-order it.
View is inserted directly into your query by PG, and then reordered
according to from_collapse_limit. Probably, problems lies in the view?
How good is it performing? Or from_collapse_l
On Wed, 25 Nov 2009, Grzegorz Jaśkiewicz wrote:
the out of order data layout is primary reason for index bloat. And that
happens , and
gets worse over time once data is more and more distributed. ("random" deletes,
etc).
That's not index bloat. Sure, having the table not in the same order as
