Re: [PERFORM] optimizing immutable vs. stable function calls?

2017-01-23 Thread Merlin Moncure
On Mon, Jan 23, 2017 at 9:10 AM, Jim Nasby wrote: > On 1/18/17 6:09 PM, David G. Johnston wrote: >> >> That would not be a productive exercise for me, or most people who just >> want >> some idea of what to expect in terms of behavior when they write and use a >> Stable

Re: [PERFORM] Backup taking long time !!!

2017-01-23 Thread julyanto SUTANDANG
Dear Jeff, Thanks for the correction and by this email, we hope that myth has gone forever :) Will do that to inform other about this matter. And agree with all of us here that: using pg_basebackup is the best approach rather than do it manually through pg_start_backup, right? Thanks and

Re: [PERFORM] Backup taking long time !!!

2017-01-23 Thread Stephen Frost
* Simon Riggs (si...@2ndquadrant.com) wrote: > On 23 January 2017 at 17:12, Jeff Janes wrote: > >> Just to make sure anyone reading the mailing list archives isn't > >> confused, running pg_start_backup does *not* make PG stop writing to > >> BASEDIR (or DATADIR, or

Re: [PERFORM] Backup taking long time !!!

2017-01-23 Thread Stephen Frost
* Jeff Janes (jeff.ja...@gmail.com) wrote: > On Mon, Jan 23, 2017 at 7:28 AM, Jim Nasby wrote: > > On 1/22/17 11:32 AM, Stephen Frost wrote: > >> The 1-second window concern is regarding the validity of a subsequent > >> incremental backup. > > > > BTW, there's a simpler

Re: [PERFORM] Backup taking long time !!!

2017-01-23 Thread Simon Riggs
On 23 January 2017 at 17:12, Jeff Janes wrote: >> Just to make sure anyone reading the mailing list archives isn't >> confused, running pg_start_backup does *not* make PG stop writing to >> BASEDIR (or DATADIR, or anything, really). PG *will* continue to write >> data into

Re: [PERFORM] Backup taking long time !!!

2017-01-23 Thread Jeff Janes
On Mon, Jan 23, 2017 at 7:28 AM, Jim Nasby wrote: > On 1/22/17 11:32 AM, Stephen Frost wrote: > >> The 1-second window concern is regarding the validity of a subsequent >> incremental backup. >> > > BTW, there's a simpler scenario here: > > Postgres touches file. >

Re: [PERFORM] Backup taking long time !!!

2017-01-23 Thread Stephen Frost
* Jeff Janes (jeff.ja...@gmail.com) wrote: > On Sun, Jan 22, 2017 at 6:57 AM, Stephen Frost wrote: > > Just to make sure anyone reading the mailing list archives isn't > > confused, running pg_start_backup does *not* make PG stop writing to > > BASEDIR (or DATADIR, or

Re: [PERFORM] Backup taking long time !!!

2017-01-23 Thread Stephen Frost
Greetings, * Torsten Zuehlsdorff (mailingli...@toco-domains.de) wrote: > I just have around 11 TB but switched to ZFS based backups only. I'm > using snapshots therefore which gives some flexibility. I can > rolback them, i can just clone it and work with a full copy as a > different cluster (and

Re: [PERFORM] Backup taking long time !!!

2017-01-23 Thread Jeff Janes
On Sun, Jan 22, 2017 at 6:57 AM, Stephen Frost wrote: > Greetings, > > * julyanto SUTANDANG (julya...@equnix.co.id) wrote: > > CORRECTION: > > > > "you might you pg_start_backup to tell the server not to write into the > > DATADIR" > > > > become > > > > "you might *use*

Re: [PERFORM] Backup taking long time !!!

2017-01-23 Thread Torsten Zuehlsdorff
Hello, Increments in pgbackrest are done on file level which is not really efficient. We have done parallelism, compression and page-level increments (9.3+) in barman fork [1], but unfortunately guys from 2ndquadrant-it don’t hurry to work on it. We're looking at page-level incremental backup

[PERFORM] performance contradiction

2017-01-23 Thread Gabriel Dodan
Hi All, I have two servers. On the first one I have postgresql version 9.6 . On the second one I have version 9.3 . I ran pgbench on both servers. First server results: scaling factor: 10 query mode: simple number of clients: 1 number of threads: 1 duration: 10 s number of transactions actually

Re: [PERFORM] Backup taking long time !!!

2017-01-23 Thread Jim Nasby
On 1/23/17 9:27 AM, Stephen Frost wrote: If you want my 2c on that, running with BLKSZ <> 8192 is playing with fire, or at least running with scissors. I've never seen it myself, but I'm under the impression that it's not unheard of for OLAP environments. Given how sensitive PG is to IO

Re: [PERFORM] Backup taking long time !!!

2017-01-23 Thread Jim Nasby
On 1/22/17 11:32 AM, Stephen Frost wrote: The 1-second window concern is regarding the validity of a subsequent incremental backup. BTW, there's a simpler scenario here: Postgres touches file. rsync notices file has different timestamp, starts copying. Postgres touches file again. If those 3

Re: [PERFORM] Backup taking long time !!!

2017-01-23 Thread Stephen Frost
* Jim Nasby (jim.na...@bluetreble.com) wrote: > On 1/20/17 9:06 AM, Stephen Frost wrote: > >All the pages are the same size, so I'm surprised you didn't consider > >just having a format along the lines of: magic+offset+page, > >magic+offset+page, magic+offset+page, etc... > > Keep in mind that if

Re: [PERFORM] Backup taking long time !!!

2017-01-23 Thread Jim Nasby
On 1/20/17 9:06 AM, Stephen Frost wrote: All the pages are the same size, so I'm surprised you didn't consider just having a format along the lines of: magic+offset+page, magic+offset+page, magic+offset+page, etc... Keep in mind that if you go that route you need to accommodate BLKSZ <> 8192.

Re: [PERFORM] optimizing immutable vs. stable function calls?

2017-01-23 Thread Jim Nasby
On 1/18/17 6:09 PM, David G. Johnston wrote: ​That would not be a productive exercise for me, or most people who just want some idea of what to expect in terms of behavior when they write and use a Stable function (Immutable and Volatile seem fairly easy to reason about). Yeah, this isn't an