From: | Leonardo F <m_lists(at)yahoo(dot)it> |
---|---|
To: | Josh Kupershmidt <schmiddy(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: I: About "Our CLUSTER implementation is pessimal" patch |
Date: | 2010-02-10 18:30:35 |
Message-ID: | 391526.82441.qm@web29015.mail.ird.yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>Perhaps you could supply a .sql file containing a testcase
> illustrating the performance benefits you tested with your patch
Sure.
Attached the updated patch (should solve a bug) and a script.
The sql scripts generates a 2M rows table ("orig"); then the
table is copied and the copy clustered using seq + sort (since
"set enable_seqscan=false;").
Then the table "orig" is copied again, and the copy clustered
using regular index scan (set enable_indexscan=true; set
enable_seqscan=false).
Then the same thing is done on a 5M rows table, and on a 10M
rows table.
On my system (Sol10 on a dual Opteron 2.8) single disc:
2M: seq+sort 11secs; regular index scan: 33secs
5M: seq+sort 39secs; regular index scan: 105secs
10M:seq+sort 83secs; regular index scan: 646secs
Maybe someone could suggest a better/different test?
Leonardo
Attachment | Content-Type | Size |
---|---|---|
sorted_cluster20100210.patch | application/octet-stream | 26.5 KB |
cluster_tests.sql | application/octet-stream | 2.8 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Teodor Sigaev | 2010-02-10 18:40:16 | Re: [CFReview] Red-Black Tree |
Previous Message | Heikki Linnakangas | 2010-02-10 18:15:32 | Re: synchronized snapshots |