| From: | Scott Carey <scott(at)richrelevance(dot)com> |
|---|---|
| To: | "<david(at)lang(dot)hm>" <david(at)lang(dot)hm> |
| Cc: | Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>, Vitalii Tymchyshyn <tivv00(at)gmail(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: Slow count(*) again... |
| Date: | 2010-10-12 16:46:08 |
| Message-ID: | 0D179340-9AD4-4118-B114-37C0B9D82FC5@richrelevance.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-performance |
On Oct 12, 2010, at 8:54 AM, <david(at)lang(dot)hm> wrote:
> On Tue, 12 Oct 2010, Craig Ringer wrote:
>
>> On 10/12/2010 04:22 PM, david(at)lang(dot)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 under some circumstances.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Scott Carey | 2010-10-12 16:50:40 | Re: Slow count(*) again... |
| Previous Message | Scott Carey | 2010-10-12 16:44:02 | Re: Slow count(*) again... |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Scott Carey | 2010-10-12 16:50:40 | Re: Slow count(*) again... |
| Previous Message | Scott Carey | 2010-10-12 16:44:02 | Re: Slow count(*) again... |