On Tue, Apr 14, 2015 at 8:41 AM, Yves Dorfsman y...@zioup.com wrote:
On 2015-04-13 17:49, Jeff Janes wrote:
One way would be to lock dirty buffers from unlogged relations into
shared_buffers (which hardly seems like a good thing) until the start of
a
super-checkpoint and then write them
On Mon, Apr 13, 2015 at 8:28 PM, David G. Johnston
david.g.johns...@gmail.com wrote:
On Mon, Apr 13, 2015 at 7:45 PM, Jim Nasby jim.na...@bluetreble.com
wrote:
There's been recent discussion of adding support for read-only tables. If
we had those, we might be able to support something
David G Johnston wrote
Well, that is half right anyway. UNLOGGED tables obey checkpoints just
like any other table. The missing feature is an option to leaved restored
the last checkpoint. Instead, not knowing whether there were changes
since the last checkpoint, the system truncated the
On 2015-04-13 17:49, Jeff Janes wrote:
One way would be to lock dirty buffers from unlogged relations into
shared_buffers (which hardly seems like a good thing) until the start of a
super-checkpoint and then write them all out as fast as possible (which kind
of defeats
Hi all. I have a pg_largeobject of ~300GB size and when I run vacuumlo -n
dbname, I get: Would remove 82172 large objects from database dbname.
So I'm running without -n to do the actual work, but it seems to take
forever. The disks are 8 SAS 10K HDD drives in RAID5. Any hints on how
Scott,
Can confirm that for pg purposes, 3.2 is basically broken in some not
to great ways. We've had servers that were overloaded at load factors
of 20 or 30 drop down to 5 or less with just a change from 3.2 to
3.11/3.13 on ubuntu 12.04
That's correct, and 3.5 shares the same problems.
On 4/14/15 10:56 AM, dgabriel wrote:
David G Johnston wrote
Well, that is half right anyway. UNLOGGED tables obey checkpoints just
like any other table. The missing feature is an option to leaved restored
the last checkpoint. Instead, not knowing whether there were changes
since the last
