Re: [GENERAL] Optimizing a read-only database

2015-05-20 Thread François Battail
Dear List, Thank you for all for your advices, even if there's not a direct and magical solution, I've now some paths to try. I really enjoy the PostgreSQL community. Wish you a nice day/night, best regards. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make chang

Re: [GENERAL] Optimizing a read-only database

2015-05-20 Thread Sameer Thakur
Hello, In addition to what has already been suggested 1. Use VACUUM FREEZE ANALYZE; Otherwise you will still have some trickle of write-activity going on, not always efficiently, despite being in read-only mode. It's because of what's referred to as Hint Bits: http://wiki.postgresql.or

Re: [GENERAL] Optimizing a read-only database

2015-05-20 Thread Sameer Thakur
Hello >That is bad advice. >If there are no writes, fsync won't hurt anyway. >Never disable fsync for anything but test systems. Yep. Its a bad way to speed up writes. Not relevant to this context and bad anyway regards Sameer -- View this message in context: http://postgresql.nabble.com/Op

Re: [GENERAL] Optimizing a read-only database

2015-05-20 Thread Sameer Thakur
Hello, >I was more dreaming of something like "disable read write locks or >mutexes" when accessing the database in read-only mode, but sadly this >case seems unhandled. You could use transactions in read only mode. They do not generate XID's,which reduces the need to do VACUUM to protect agai

Re: [GENERAL] Optimizing a read-only database

2015-05-20 Thread Albe Laurenz
Sameer Thakur wrote: > You could disable fsync as write reliability is not relevant That is bad advice. If there are no writes, fsync won't hurt anyway. Never disable fsync for anything but test systems. Yours, Laurenz Albe -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) T

Re: [GENERAL] Optimizing a read-only database

2015-05-20 Thread Sameer Thakur
Hello, You could disable fsync as write reliability is not relevant regards Sameer -- View this message in context: http://postgresql.nabble.com/Optimizing-a-read-only-database-tp5849746p5850103.html Sent from the PostgreSQL - general mailing list archive at Nabble.com. -- Sent via pgsql-gen

Re: [GENERAL] Optimizing a read-only database

2015-05-19 Thread hari . fuchs
François Battail writes: > 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. You could also raise the

Re: [GENERAL] Optimizing a read-only database

2015-05-18 Thread François Battail
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).

Re: [GENERAL] Optimizing a read-only database

2015-05-18 Thread William Dunn
On Mon, May 18, 2015 at 10:54 AM, François Battail < francois.batt...@sipibox.fr> wrote: > Le 18/05/2015 16:38, William Dunn a écrit : > > * You can also run a CLUSTER command on one of your indexes to group >> data that is frequently accessed together into the same segment of >> disk so

Re: [GENERAL] Optimizing a read-only database

2015-05-18 Thread François Battail
Le 18/05/2015 16:38, William Dunn a écrit : Thank you William, * With read-only work loads you can make shared_buffers very large, like 40% of RAM available to the database. Usually you would keep it lower because in a write heavy workload large shared_buffers causes checkpoints t

Re: [GENERAL] Optimizing a read-only database

2015-05-18 Thread François Battail
Le 18/05/2015 16:20, Andreas Kretschmer a écrit : Thank you Andreas, you can set fillfactor to 100 Yes, but it's already the default value according to documentation. And you can disable VACUUM. Already done ;-) I was more dreaming of something like "disable read write locks or mutexes"

Re: [GENERAL] Optimizing a read-only database

2015-05-18 Thread William Dunn
Hello François, - With read-only work loads you can make shared_buffers very large, like 40% of RAM available to the database. Usually you would keep it lower because in a write heavy workload large shared_buffers causes checkpoints to have huge IO, but since you are not making changes

Re: [GENERAL] Optimizing a read-only database

2015-05-18 Thread Andreas Kretschmer
> François Battail hat am 18. Mai 2015 um 16:07 > geschrieben: > > > Dear List, > > I would like to know if somebody is aware of tricks for optimizing > PostgreSQL settings for a read-only database. you can set fillfactor to 100 alter table ... set (fillfactor = 100), see http://www.postg

[GENERAL] Optimizing a read-only database

2015-05-18 Thread François Battail
Dear List, I would like to know if somebody is aware of tricks for optimizing PostgreSQL settings for a read-only database. I have a big read-only database (> 1.10^9 records splitted into ~ 10 tables) using GiST and Btree indexes, no foreign keys on tables at all. I believe that not doing loc