Re: Slow count(*) again...
От | Scott Carey |
---|---|
Тема | Re: Slow count(*) again... |
Дата | |
Msg-id | 0D179340-9AD4-4118-B114-37C0B9D82FC5@richrelevance.com обсуждение исходный текст |
Ответ на | Re: Slow count(*) again... (david@lang.hm) |
Ответы |
Re: Slow count(*) again...
|
Список | pgsql-performance |
On Oct 12, 2010, at 8:54 AM, <david@lang.hm> wrote: > On Tue, 12 Oct 2010, Craig Ringer wrote: > >> On 10/12/2010 04:22 PM, david@lang.hm wrote: >> >>> from a PR point of view, speeding up the trivil count(*) case could be >>> worth it, just to avoid people complaining about it not being fast. >> >> At the cost of a fair bit more complexity, though, and slowing everything >> else down. > > complexity probably, although given how complex the planner is already is > this significant? > > as far as slowing everything else down, why would it do that? (beyond the > simple fact that any new thing the planner can do makes the planner take a > little longer) > > David Lang > I wouldn't even expect the planner to do more work. An Index Scan can simply avoid going to the tuples for visibility undersome circumstances.
В списке pgsql-performance по дате отправления: