| From: | Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
| Cc: | Josh Kupershmidt <schmiddy(at)gmail(dot)com>, Leonardo Francalanci <m_lists(at)yahoo(dot)it>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: I: About "Our CLUSTER implementation is pessimal" patch |
| Date: | 2010-09-29 05:12:59 |
| Message-ID: | AANLkTi=mTyE_jSL2LZm0MWB4QXesHGyKv=07mRPiS5s-@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Sep 29, 2010 at 1:27 PM, Alvaro Herrera
<alvherre(at)commandprompt(dot)com> wrote:
>> I see a consistent
>> ~10% advantage for the sequential scan clusters.
>
> 10% is nothing. I was expecting this patch would give an order of
> magnitude of improvement or somethine like that in the worst cases of
> the current code (highly unsorted input)
Yes. It should be x10 faster than ordinary method in the worst cases.
I have a performance result of pg_reorg, that performs as same as
the patch. It shows 16 times faster than the old CLUSTER. In addition,
it was slow if not fragmented. (So, it should not be "consistent".)
http://reorg.projects.postgresql.org/
--
Itagaki Takahiro
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Darren Duncan | 2010-09-29 05:20:38 | Re: Proposal: plpgsql - "for in array" statement |
| Previous Message | Alvaro Herrera | 2010-09-29 04:27:50 | Re: I: About "Our CLUSTER implementation is pessimal" patch |