tim_wilson writes:
> On a 9.3.1 server , I have a key busy_table in that is hit by most
> transactions running on our system. One DB's copy of this table has 60K rows
> and 1/3 of that tables rows can updated every minute.
> Autovacuum autovacuum_analyze_scale_factor is set 0.02, so that analyse
On Thu, May 15, 2014 at 10:52 AM, Tom Lane wrote:
> Scott Marlowe writes:
>> OK so we have a query that does OK in 8.4, goes to absolute crap in
>> 9.2 and then works great in 9.3. Thing is we've spent several months
>> regression testing 9.2 and no time testing 9.3, so we can't just "go
>> to 9.
"Huang, Suya" writes:
> Thank you Tom. But the time spent on scanning table test1 is less than 1
> second (91.738 compares to 87.869), so I guess this shouldn't be the issue?
No, the point is that the bad rowcount estimate (and, possibly, lack of
stats about join column contents) causes the plan
On Mon, May 19, 2014 at 4:47 PM, Geoff Hull wrote:
> I am sending this on behalf of my colleague who tried to post to this list
> last year but without success, then also tried
> pgsql-performance-ow...@postgresql.org but without getting a reply.
>
> I have recently re-tested this in P/G version 9
