Re: Slow count(*) again...

Поиск
Список
Период
Сортировка
От Scott Carey
Тема Re: Slow count(*) again...
Дата
Msg-id AFE68F36-2B41-4065-A6EB-78C908FBEC95@richrelevance.com
обсуждение исходный текст
Ответ на Re: Slow count(*) again...  (Scott Carey <scott@richrelevance.com>)
Список pgsql-performance
On Oct 12, 2010, at 9:46 AM, Scott Carey wrote:

>
> 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
visibilityunder some circumstances. 
>
>
Of course, the planner has to ....  Otherwise it won't choose the Index Scan over the sequential scan.  So the cost of
indexscans when all the info other than visibility is in the index would need to be lowered. 


> --
> Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance


В списке pgsql-performance по дате отправления:

Предыдущее
От: Scott Carey
Дата:
Сообщение: Re: Slow count(*) again...
Следующее
От: Chris Browne
Дата:
Сообщение: Re: large dataset with write vs read clients