Re: [HACKERS] increasing the default WAL segment size - Mailing list pgsql-hackers

From Jeff Janes
Subject Re: [HACKERS] increasing the default WAL segment size
Date
Msg-id CAMkU=1wdfFc_WQFzgVC-fNXPi+G3XmWPt_mUe0JKDgwaCSLepQ@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] increasing the default WAL segment size  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: [HACKERS] increasing the default WAL segment size  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Re: increasing the default WAL segment size  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
On Thu, Mar 23, 2017 at 1:45 PM, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote:
On 3/22/17 17:33, David Steele wrote:

> and I doubt that most tool writers would be quick to
> add support for a feature that very few people (if any) use.

I'm not one of those tool writers, although I have written my share of
DBA scripts over the years, but I wonder why those tools would really
care.  They are handed files with predetermined names to archive, and
for restore files with predetermined names are requested back from them.
 What else do they need?  If something is missing that requires them to
parse file names, then maybe that should be added.


I have a pg_restore which predicts the file 5 files ahead of the one it was asked for, and initiates a pre-fetch and decompression of it. Then it delivers the file it was asked for, either by pulling it out of the pre-staging area set up by the N-5th invocation, or by going directly to the archive to get it.  This speeds up play-back dramatically when the files are stored compressed and non-local.

That is why I need to know how the files are numbered.  I don't think that that makes much of a difference, though.  Any change is going to break that, no matter which change.  Then I'll fix it.  

If we are going to break it, I'd prefer to just do away with the 'segment' thing altogether.  You have timelines, and you have files.  That's it.

Cheers,

Jeff

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [HACKERS] No more libedit?! - openssl plans to switch to APL2
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] WIP: Faster Expression Processing v4