Palle Girgensohn <girgen@pingpong.net> writes: > When running > select max("when") from login where userid='userid' > it takes a second or two, but when adding "group by userid" the planner > decides on using another plan, and it gets *much* faster. See example below. It's only faster for cases where there are few or no rows for the particular userid ... > Number of tuples per user varies from zero to a couple of thousands. The planner is using an intermediate estimate of 406 rows. You might be well advised to increase the statistics target for login.userid --- with luck that would help it to choose the right plan type for both common and uncommon userids. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq

Palle Girgensohn <girgen@pingpong.net> writes: > Unfortunately, altering statistics doesn't help. I see no difference when > altering the value from 10 (default) to 100, 1000 or 100000. :-( Um, you did re-ANALYZE the table after changing the setting? regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org

Palle Girgensohn <girgen@pingpong.net> writes: > --On torsdag, november 01, 2007 11.06.57 -0400 Tom Lane <tgl@sss.pgh.pa.us> > wrote: >> Um, you did re-ANALYZE the table after changing the setting? > alter table login alter userid SET statistics 1000; > vacuum analyze login; Hm, that's the approved procedure all right. But the plans didn't change at all? Not even the estimated number of rows? regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org