Re: I: About "Our CLUSTER implementation is pessimal" patch
Leonardo Francalanci <m_lists@yahoo.it>
From: Leonardo F <m_lists@yahoo.it>
To: Josh Kupershmidt <schmiddy@gmail.com>
Cc: pgsql-hackers@postgresql.org
Date: 2010-02-10T18:30:35Z
Lists: pgsql-hackers
Attachments
- sorted_cluster20100210.patch (application/octet-stream) patch
- cluster_tests.sql (application/octet-stream)
>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