Re: [PERFORM] same query different execution plan (hash join vs. semi-hash join)

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? -Original Message- From: Tom Lane [mailto:t...@sss.pgh.pa.us] Sent: Friday, May 16, 2014 12:58 PM To: Huang, Suya Cc: pgsql-performance@po

[PERFORM] View has different query plan than select statement

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.3.4 with the same results: Hi, I have created a table

[PERFORM] Re: autovacuum vacuum creates bad statistics for planner when it log index scans: 0

Just to add a little more detail about my busy_table 1) there are no rows deleted 2) 98% of updates are HOT 3) there are two DB's on this postgres instance both with the same table, both seeing the same issue -- View this message in context: http://postgresql.1045698.n5.nabble.com/autovacuum-v

[PERFORM] autovacuum vacuum creates bad statistics for planner when it log index scans: 0

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 runs nearly every minute. Bu