Hi Moreno:
On Wed, Aug 3, 2016 at 1:07 PM, Moreno Andreo wrote:
It's already been answered, but as it seems to be answering a chunk of
my mail...
> Should I keep fsync off? I'd think it would be better leaving it on, right?
Yes. If you have to ask wether fsync should be on, it should.
I mean,
Il 03/08/2016 18:01, Jeff Janes ha scritto:
On Thu, Jul 28, 2016 at 6:25 AM, Moreno Andreo wrote:
Hi folks! :-)
I'm about to bring up my brand new production server and I was wondering if
it's possible to calculate (approx.) the WAL directory size.
I have to choose what's better in terms of cos
On Thu, Jul 28, 2016 at 6:25 AM, Moreno Andreo wrote:
> Hi folks! :-)
> I'm about to bring up my brand new production server and I was wondering if
> it's possible to calculate (approx.) the WAL directory size.
> I have to choose what's better in terms of cost vs. performance (we are on
> Google C
On Thu, Jul 28, 2016 at 6:33 AM, David G. Johnston
wrote:
> On Thu, Jul 28, 2016 at 9:25 AM, Moreno Andreo
> wrote:
>>
>> I've read somewhere that the formula should be 16 MB * 3 *
>> checkpoint_segment in size.
>
> [...]
>
>>
>> Using the above formula I have:
>> 16 MB * 3 * 1 GB
>> that lea
Il 03/08/2016 14:12, Michael Paquier ha scritto:
On Wed, Aug 3, 2016 at 8:07 PM, Moreno Andreo wrote:
Should I keep fsync off? I'd think it would be better leaving it on, right?
>From the docs:
https://www.postgresql.org/docs/9.6/static/runtime-config-wal.html#RUNTIME-CONFIG-WAL-SETTINGS
Whil
On Wed, Aug 3, 2016 at 8:07 PM, Moreno Andreo wrote:
> Should I keep fsync off? I'd think it would be better leaving it on, right?
>From the docs:
>https://www.postgresql.org/docs/9.6/static/runtime-config-wal.html#RUNTIME-CONFIG-WAL-SETTINGS
While turning off fsync is often a performance benefi
Il 29/07/2016 17:26, Francisco Olarte ha scritto:
Hi:
On Fri, Jul 29, 2016 at 10:35 AM, Moreno Andreo
wrote:
After Andreas post and thinking about it a while, I went to the decision
that it's better not to use RAM but another persistent disk, because there
can be an instant between when a WAL
Il 29/07/2016 15:30, David G. Johnston
ha scritto:
On Fri, Jul 29, 2016 at
7:08 AM, Moreno Andreo wrote:
R
Hi:
On Fri, Jul 29, 2016 at 10:35 AM, Moreno Andreo
wrote:
> After Andreas post and thinking about it a while, I went to the decision
> that it's better not to use RAM but another persistent disk, because there
> can be an instant between when a WAL is written and it's fsync'ed, and if a
> failur
To: FarjadFarid(ChkNet)
;
pgsql-general@postgresql.org
Subject: Re: [SPAM] Re: [GENERAL] WAL directory
size calculation
Il 29/07/2016 11:44, FarjadFarid(ChkNet)
ha scritto:
On Fri, Jul 29, 2016 at 7:08 AM, Moreno Andreo
wrote:
> R
> egarding backups I disagree. Files related to database must be consistent
> to the database itself, so backup must be done saving both database and
> images.
>
I'd suggest you consider that such binary data be defined as immutable.
T
l.org
<mailto:pgsql-general-ow...@postgresql.org>
[mailto:pgsql-general-ow...@postgresql.org] On Behalf Of Moreno Andreo
Sent: 29 July 2016 10:19
To: pgsql-general@postgresql.org <mailto:pgsql-general@postgresql.org>
Subject: Re: [SPAM] Re: [GENERAL] WAL directory size calculation
Il
. They also distributed servers around the
world.
Hope this helps.
From: Moreno Andreo [mailto:moreno.and...@evolu-s.it]
Sent: 29 July 2016 12:08
To: FarjadFarid(ChkNet) ;
pgsql-general@postgresql.org
Subject: Re: [SPAM] Re: [GENERAL] WAL directory size calculation
Il 29/07/2016
[SPAM] Re: [GENERAL] WAL directory
size calculation
Il 29/07/2016 10:43, John R Pierce ha
scritto:
Aside of this
luck.
From: pgsql-general-ow...@postgresql.org
[mailto:pgsql-general-ow...@postgresql.org] On Behalf Of Moreno Andreo
Sent: 29 July 2016 10:19
To: pgsql-general@postgresql.org
Subject: Re: [SPAM] Re: [GENERAL] WAL directory size calculation
Il 29/07/2016 10:43, John R Pierce ha
@postgresql.org
Subject: Re: [SPAM] Re: [GENERAL] WAL directory size calculation
Il 29/07/2016 10:43, John R Pierce ha scritto:
Aside of this, I'm having 350 DBs that sum up a bit more than 1 TB, and plan
to use wal_level=archive because I plan to have a backup server with barman.
Il 29/07/2016 10:43, John R Pierce ha
scritto:
Aside of this,
I'm having 350 DBs that sum up a bit more than 1 TB, and
plan
to use wal_level=archive because I plan to have a backup
Aside of this, I'm having 350 DBs that sum up a bit more than 1 TB,
and plan
to use wal_level=archive because I plan to have a backup server with
barman.
With that many databases with that so many objectsand undoubtable client
connections, I'd want to spread that across a cluster of smaller
Il 28/07/2016 20:45, Francisco Olarte ha scritto:
On Thu, Jul 28, 2016 at 3:25 PM, Moreno Andreo wrote:
Obviously ramdisk will be times faster disk, but having a, say, 512 GB
ramdisk will be a little too expensive :-)
Besides defeating the purpose of WAL, if you are going to use non
persistent
On Thu, Jul 28, 2016 at 9:54 AM, Andreas Kretschmer wrote:
> Without Replication 1 GB would be fine, even with replication. But it must
> be realible!
>
>
The required size of WAL depends on what your intended checkpoint_timeout
vs. the amount
of WAL generated from data turnover is. A rather smal
On Thu, Jul 28, 2016 at 3:25 PM, Moreno Andreo wrote:
> Obviously ramdisk will be times faster disk, but having a, say, 512 GB
> ramdisk will be a little too expensive :-)
Besides defeating the purpose of WAL, if you are going to use non
persistent storage for WAL you could as well use minimal le
Il 28/07/2016 15:33, David G. Johnston
ha scritto:
On Thu, Jul 28, 2016 at
9:25 AM, Moreno Andreo wrote:
I've
read somewhere that the formula should be 16 MB * 3 *
Il 28/07/2016 15:54, Andreas Kretschmer ha scritto:
Am 28.07.2016 um 15:25 schrieb Moreno Andreo:
Hi folks! :-)
I'm about to bring up my brand new production server and I was
wondering if it's possible to calculate (approx.) the WAL directory
size.
I have to choose what's better in terms of co
Am 28.07.2016 um 15:25 schrieb Moreno Andreo:
Hi folks! :-)
I'm about to bring up my brand new production server and I was
wondering if it's possible to calculate (approx.) the WAL directory size.
I have to choose what's better in terms of cost vs. performance (we
are on Google Cloud Platform)
On Thu, Jul 28, 2016 at 9:25 AM, Moreno Andreo
wrote:
> I've read somewhere that the formula should be 16 MB * 3 *
> checkpoint_segment in size.
>
[...]
> Using the above formula I have:
> 16 MB * 3 * 1 GB
> that leads to to ... uh .. 48000 TB?
>
You seem to be mis-remembering the formu
Hi folks! :-)
I'm about to bring up my brand new production server and I was wondering
if it's possible to calculate (approx.) the WAL directory size.
I have to choose what's better in terms of cost vs. performance (we are
on Google Cloud Platform) between a ramdisk or a separate persistent
dis
26 matches
Mail list logo