Re: [GENERAL] simple query with radically different plan after 9.0 - 9.2 upgrade

2013-11-17 Thread Kevin Goess
On Tue, Nov 12, 2013 at 2:47 PM, Tom Lane t...@sss.pgh.pa.us wrote: That's right, we store 90 days and roll up data older than that into a different table. Ah-hah. The default statistics target is 100, so indeed ANALYZE is going to be able to fit every date entry in the table into the

Re: [GENERAL] simple query with radically different plan after 9.0 - 9.2 upgrade

2013-11-12 Thread Tom Lane
Kevin Goess kgo...@bepress.com writes: We noticed a big change after upgrading from 9.0 to 9.2. For *yesterday's*date, the query plan is fine, like you'd expect articles_1= explain (analyze, buffers) select 1 from hits_user_daily_count where userid = 1590185 and date =

Re: [GENERAL] simple query with radically different plan after 9.0 - 9.2 upgrade

2013-11-12 Thread Kevin Goess
Thanks for the reply! Your analysis matches everything I see here, so what you say is probably the case. As to why it changed for us with the 9.0 = 9.2 upgrade, I also don't know--the change was pretty dramatic though. Since we've compensated for it, and since you say the current behavior is

Re: [GENERAL] simple query with radically different plan after 9.0 - 9.2 upgrade

2013-11-12 Thread Tom Lane
Kevin Goess kgo...@bepress.com writes: Now, the only way to get to a zero selectivity estimate for var = const is if the planner believes that the pg_stats most-common-values list for the column is complete, and the constant is nowhere in the list. So one plausible explanation for the change

[GENERAL] simple query with radically different plan after 9.0 - 9.2 upgrade

2013-09-20 Thread Kevin Goess
Given this table articles_1= \d hits_user_daily_count; Table public.hits_user_daily_count Column | Type | Modifiers ---+-+--- userid| integer | not null date | date| not null