From: | François Battail <francois(dot)battail(at)sipibox(dot)fr> |
---|---|
To: | PostgreSQL General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Optimizing a read-only database |
Date: | 2015-05-18 15:37:50 |
Message-ID: | 555A074E.2010805@sipibox.fr |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Le 18/05/2015 17:20, William Dunn a écrit :
Hello William,
> Hello François - the CLUSTER command doesn't have to do with where your
> indexes are. What the CLUSTER command does is physically sort the table
> data based on the index (Doc:
> http://www.postgresql.org/docs/devel/static/sql-cluster.html) So for
> example if you have a column called 'region_code' with an index and
> CLUSTER the table by that index all the rows for 'region_code'=15 will
> be located next to each other on disk and can be read in the same IO
> operation. The usual disadvantage of CLUSTER is that it does not
> maintain itself, but since your data is read-only that doesn't matter.
> And yes you can still have the index on an SSD and the source table on
> slower storage.
My bad, got it. May be interesting but as I have a lot of indexes it
will be hard to test and to choose the best candidate. No idea of how it
can affect EWKB data indexed by a GiST (PostGIS) index, but it's
something to try just to know.
Thanks a lot, may be I will be able to do something with that!
Best regards
From | Date | Subject | |
---|---|---|---|
Next Message | Geoff Montee | 2015-05-18 16:23:32 | Re: SQL Server access from PostgreSQL |
Previous Message | John R Pierce | 2015-05-18 15:24:46 | Re: |