On 2.3.2012 03:05, Claudio Freire wrote:
On Thu, Mar 1, 2012 at 10:13 PM, Tomas Vondra t...@fuzzy.cz wrote:
Maybe. I still am not sure how fsync=off affects the eviction in your
opinion. I think it does not (or just very remotely) and you were saying
the opposite. IMHO the eviction of (dirty)
On Tue, Feb 28, 2012 at 3:46 PM, Stefan Keller sfkel...@gmail.com wrote:
2012/2/28 Claudio Freire klaussfre...@gmail.com:
In the OP, you say There is enough main memory to hold all table
contents.. I'm assuming, there you refer to your current system, with
4GB memory.
Sorry for the
On Thu, Mar 1, 2012 at 9:57 AM, Jeff Janes jeff.ja...@gmail.com wrote:
On Tue, Feb 28, 2012 at 3:46 PM, Stefan Keller sfkel...@gmail.com wrote:
2012/2/28 Claudio Freire klaussfre...@gmail.com:
In the OP, you say There is enough main memory to hold all table
contents.. I'm assuming, there you
Just curious ... has anyone tried using a ram disk as the PG primary and
DRBD as the means to make it persistent?
On Mar 1, 2012 11:35 AM, Scott Marlowe scott.marl...@gmail.com wrote:
On Thu, Mar 1, 2012 at 9:57 AM, Jeff Janes jeff.ja...@gmail.com wrote:
On Tue, Feb 28, 2012 at 3:46 PM, Stefan
2012/3/1 Jeff Janes jeff.ja...@gmail.com:
On Tue, Feb 28, 2012 at 3:46 PM, Stefan Keller sfkel...@gmail.com wrote:
2012/2/28 Claudio Freire klaussfre...@gmail.com:
In the OP, you say There is enough main memory to hold all table
contents.. I'm assuming, there you refer to your current system,
On 03/01/2012 05:52 PM, Stefan Keller wrote:
These are the current modified settings in postgresql.conf:
shared_buffers = 128MB
work_mem = 3MB
These are extremely low settings on virtually any modern computer. I
usually look to set shared buffers in numbers of Gb and work_mem at
least in
On Thu, Mar 1, 2012 at 8:08 PM, Andrew Dunstan and...@dunslane.net wrote:
These are extremely low settings on virtually any modern computer. I usually
look to set shared buffers in numbers of Gb and work_mem at least in tens if
not hundreds of Mb for any significantly sized database.
For a
On Thu, Mar 1, 2012 at 4:23 PM, Claudio Freire klaussfre...@gmail.com wrote:
For a read-only database, as was discussed, a lower shared_buffers
settings makes sense. And 128M is low enough, I'd guess.
Setting work_mem to hundreds of MB in a 4G system is suicide. Tens
even is dangerous.
Why
On Wed, Feb 29, 2012 at 7:28 AM, Stefan Keller sfkel...@gmail.com wrote:
2012/2/29 Stefan Keller sfkel...@gmail.com:
2012/2/29 Jeff Janes jeff.ja...@gmail.com:
It's quite possible the vacuum full is thrashing your disk cache due
to maintainance_work_mem. You can overcome this issue with the
On Thu, Mar 1, 2012 at 9:28 PM, Peter van Hardenberg p...@pvh.ca wrote:
Setting work_mem to hundreds of MB in a 4G system is suicide. Tens
even is dangerous.
Why do you say that? We've had work_mem happily at 100MB for years. Is
there a particular degenerate case you're concerned about?
Me
On 28.2.2012 17:42, Claudio Freire wrote:
On Tue, Feb 28, 2012 at 1:05 PM, Tomas Vondra t...@fuzzy.cz wrote:
On 28 Únor 2012, 15:24, Claudio Freire wrote:
It speeds a lot more than the initial load of data.
Assuming the database is read-only, but not the filesystem (ie: it's
not a slave, in
On 03/01/2012 07:58 PM, Claudio Freire wrote:
On Thu, Mar 1, 2012 at 9:28 PM, Peter van Hardenbergp...@pvh.ca wrote:
Setting work_mem to hundreds of MB in a 4G system is suicide. Tens
even is dangerous.
Why do you say that? We've had work_mem happily at 100MB for years. Is
there a
On Thu, Mar 1, 2012 at 10:13 PM, Tomas Vondra t...@fuzzy.cz wrote:
Maybe. I still am not sure how fsync=off affects the eviction in your
opinion. I think it does not (or just very remotely) and you were saying
the opposite. IMHO the eviction of (dirty) buffers is either very fast
or slow, no
On Tue, Feb 28, 2012 at 2:41 PM, Claudio Freire klaussfre...@gmail.com wrote:
On Tue, Feb 28, 2012 at 5:48 PM, Stefan Keller sfkel...@gmail.com wrote:
P.S. And yes, the database is aka 'read-only' and truncated and
re-populated from scratch every night. fsync is off so I don't care
about ACID.
On Wed, Feb 29, 2012 at 12:16 PM, Jeff Janes jeff.ja...@gmail.com wrote:
But on many implementations, that will not work. tar detects the
output is going to the bit bucket, and so doesn't bother to actually
read the data.
Really? Getting smart on us?
Shame on it. Who asked it to be smart?
2012/2/29 Jeff Janes jeff.ja...@gmail.com:
It's quite possible the vacuum full is thrashing your disk cache due
to maintainance_work_mem. You can overcome this issue with the tar
trick, which is more easily performed as:
tar cf /dev/null $PG_DATA/base
But on many implementations, that will
2012/2/29 Stefan Keller sfkel...@gmail.com:
2012/2/29 Jeff Janes jeff.ja...@gmail.com:
It's quite possible the vacuum full is thrashing your disk cache due
to maintainance_work_mem. You can overcome this issue with the tar
trick, which is more easily performed as:
tar cf /dev/null
Hi Wales
2012/2/27 Wales Wang wormw...@yahoo.com wrote:
There are many approach for PostgreSQL in-memory.
The quick and easy way is making slave pgsql run on persistent RAM
filesystem, the slave is part of master/slave replication cluster.
The fstab and script make RAM file system persistent
On Tue, Feb 28, 2012 at 5:30 AM, Stefan Keller sfkel...@gmail.com wrote:
But what I'm finally after is a solution, where records don't get
pushed back to disk a.s.a.p. but rather got hold in memory as long as
possible assuming that there is enough memory.
fsync = off ?
--
Sent via
On 28 Únor 2012, 14:08, Claudio Freire wrote:
On Tue, Feb 28, 2012 at 5:30 AM, Stefan Keller sfkel...@gmail.com wrote:
But what I'm finally after is a solution, where records don't get
pushed back to disk a.s.a.p. but rather got hold in memory as long as
possible assuming that there is enough
On Tue, Feb 28, 2012 at 10:38 AM, Tomas Vondra t...@fuzzy.cz wrote:
On 28 Únor 2012, 14:08, Claudio Freire wrote:
On Tue, Feb 28, 2012 at 5:30 AM, Stefan Keller sfkel...@gmail.com wrote:
But what I'm finally after is a solution, where records don't get
pushed back to disk a.s.a.p. but rather
On 28 Únor 2012, 14:52, Claudio Freire wrote:
On Tue, Feb 28, 2012 at 10:38 AM, Tomas Vondra t...@fuzzy.cz wrote:
On 28 Únor 2012, 14:08, Claudio Freire wrote:
On Tue, Feb 28, 2012 at 5:30 AM, Stefan Keller sfkel...@gmail.com
wrote:
But what I'm finally after is a solution, where records
On Tue, Feb 28, 2012 at 11:15 AM, Tomas Vondra t...@fuzzy.cz wrote:
I haven't investigated why exactly the data are not cached initially, but
none of the options that I can think of could be fixed by setting
fsync=off. That's something that influences writes (not read-only
database) and I
On Tue, Feb 28, 2012 at 12:30 AM, Stefan Keller sfkel...@gmail.com wrote:
Thank you for the tipp.
Making slave pgsql run on persistent RAM filesystem is surely at least
a possibility which I'll try out.
But what I'm finally after is a solution, where records don't get
pushed back to disk
On 28 Únor 2012, 15:24, Claudio Freire wrote:
On Tue, Feb 28, 2012 at 11:15 AM, Tomas Vondra t...@fuzzy.cz wrote:
I haven't investigated why exactly the data are not cached initially,
but
none of the options that I can think of could be fixed by setting
fsync=off. That's something that
On Tue, Feb 28, 2012 at 1:05 PM, Tomas Vondra t...@fuzzy.cz wrote:
On 28 Únor 2012, 15:24, Claudio Freire wrote:
It speeds a lot more than the initial load of data.
Assuming the database is read-only, but not the filesystem (ie: it's
not a slave, in which case all this is moot, as you said,
On Tue, Feb 28, 2012 at 5:48 PM, Stefan Keller sfkel...@gmail.com wrote:
P.S. And yes, the database is aka 'read-only' and truncated and
re-populated from scratch every night. fsync is off so I don't care
about ACID. After the indexes on name, hstore and geometry are
generated I do a VACUUM
2012/2/28 Claudio Freire klaussfre...@gmail.com:
On Tue, Feb 28, 2012 at 5:48 PM, Stefan Keller sfkel...@gmail.com wrote:
P.S. And yes, the database is aka 'read-only' and truncated and
re-populated from scratch every night. fsync is off so I don't care
about ACID. After the indexes on name,
There are many approach for PostgreSQL in-memory.
The quick and easy way is making slave pgsql run on persistent RAM filesystem,
the slave is part of master/slave replication cluster.
The fstab and script make RAM file system persistent is below:
Setup:
First, create a mountpoint for the disk
Le dimanche 26 février 2012 01:16:08, Stefan Keller a écrit :
Hi,
2011/10/24 Stephen Frost sfr...@snowman.net wrote
Now, we've also been discussing ways to have PG automatically
re-populate shared buffers and possibly OS cache based on what was in
memory at the time of the last
You can try PostgreSQL 9.x master/slave replication, then try run slave
on persistent RAM Fileystem(tmpfs)
So, access your all data from slave PostgreSQL that run on tmpfs..
发件人： Jeff Janes jeff.ja...@gmail.com
收件人： Stefan Keller sfkel...@gmail.com
抄送：
Hi Jeff and Wales,
2012/2/26 Jeff Janes jeff.ja...@gmail.com wrote:
The problem is that the initial queries are too slow - and there is no
second chance. I do have to trash the buffer every night. There is
enough main memory to hold all table contents.
Just that table, or the entire
* Stefan Keller (sfkel...@gmail.com) wrote:
So, are there any developments going on with PostgreSQL as Stephen
suggested in the former thread?
While the idea has been getting kicked around, I don't know of anyone
actively working on developing code to implement it.
Thanks,
On 02/25/2012 06:16 PM, Stefan Keller wrote:
1. How can I warm up or re-populate shared buffers of Postgres?
2. Are there any hints on how to tell Postgres to read in all table
contents into memory?
Yours, Stefan
How about after you load the data, vacuum freeze it, then do something like:
2012/2/26 Andy Colson a...@squeakycode.net wrote:
On 02/25/2012 06:16 PM, Stefan Keller wrote:
1. How can I warm up or re-populate shared buffers of Postgres?
2. Are there any hints on how to tell Postgres to read in all table
contents into memory?
Yours, Stefan
How about after you load
On 02/26/2012 01:11 PM, Stefan Keller wrote:
2012/2/26 Andy Colsona...@squeakycode.net wrote:
On 02/25/2012 06:16 PM, Stefan Keller wrote:
1. How can I warm up or re-populate shared buffers of Postgres?
2. Are there any hints on how to tell Postgres to read in all table
contents into memory?
Le dimanche 26 février 2012 01:16:08, Stefan Keller a écrit :
Hi,
2011/10/24 Stephen Frost sfr...@snowman.net wrote
Now, we've also been discussing ways to have PG automatically
re-populate shared buffers and possibly OS cache based on what was in
memory at the time of the last
Hi,
2012/2/26 Cédric Villemain ced...@2ndquadrant.fr wrote:
1. How can I warm up or re-populate shared buffers of Postgres?
There was a patch proposed for postgresql which purpose was to
Which patch are you referring to?
snapshot/Restore postgresql buffers, but it is still not sure how far
On Sun, Feb 26, 2012 at 2:56 AM, Stefan Keller sfkel...@gmail.com wrote:
Hi Jeff and Wales,
2012/2/26 Jeff Janes jeff.ja...@gmail.com wrote:
The problem is that the initial queries are too slow - and there is no
second chance. I do have to trash the buffer every night. There is
enough main
Hi,
2011/10/24 Stephen Frost sfr...@snowman.net wrote
Now, we've also been discussing ways to have PG automatically
re-populate shared buffers and possibly OS cache based on what was in
memory at the time of the last shut-down, but I'm not sure that would
help your case either since you're
On Sat, Feb 25, 2012 at 4:16 PM, Stefan Keller sfkel...@gmail.com wrote:
I'd like to come back on the issue of aka of in-memory key-value database.
To remember, it contains table definition and queries as indicated in
the appendix [0]. There exist 4 other tables of similar structure.
There
41 matches
Mail list logo
