-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/15/2014 02:15 PM, Heikki Linnakangas wrote:
> You're counting XLogRecData structs, not backup blocks. Each
> backup block typically consists of three XLogRecData structs, one
> to record a BkpBlock struct, one to record the data before the
> unus
On 04/15/2014 11:53 PM, Joe Conway wrote:
One more question before I get to that. I had applied the following
patch to XLogInsert
8<--
diff --git a/src/backend/access/transam/xlog.c
b/src/backend/access/transam/xlog.c
index 2f71590..e39cd37 100644
- --- a/src/backend/acce
Joe Conway writes:
> In other words, based on my inserted logic, it appears that there are
> 5 and 6 backup blocks on a fairly regular basis.
> However in xlog.h it says:
> 8<--
> * If we backed up any disk blocks with the XLOG record, we use flag
> * bits in xl_info to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/14/2014 04:34 PM, Joe Conway wrote:
> On 04/14/2014 04:25 PM, Andres Freund wrote:
>> On 2014-04-14 16:22:48 -0700, Joe Conway wrote:
>>> That'll help performance, but lets say I generally keep WAL
>>> files for PITR and don't turn that off befor
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/14/2014 05:40 PM, Stephen Frost wrote:
> This sounds like a great example of the unlogged table -> logged
> table use-case and makes me wonder if we could provide an
> optimization similar to the existing CREATE TABLE + COPY under
> wal_level = m
* Joe Conway (m...@joeconway.com) wrote:
> That's the thing. I'm sure there is tuning and other things to improve
> this particular case, but creating over 20 times as much WAL as real
> data seems like pathological behavior to me.
Setting things up such that you are updating a single value on eac
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/14/2014 04:25 PM, Andres Freund wrote:
> On 2014-04-14 16:22:48 -0700, Joe Conway wrote:
>> That'll help performance, but lets say I generally keep WAL files
>> for PITR and don't turn that off before starting -- shouldn't I
>> be very surprised
On 2014-04-14 16:22:48 -0700, Joe Conway wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 04/14/2014 04:17 PM, Tom Lane wrote:
> > Andres Freund writes:
> >> On 2014-04-14 14:33:03 -0700, Joe Conway wrote:
> >>> checkpoint_segments = 96 checkpoint_timeout = 10min
> >
> >> I bet yo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/14/2014 04:17 PM, Tom Lane wrote:
> Andres Freund writes:
>> On 2014-04-14 14:33:03 -0700, Joe Conway wrote:
>>> checkpoint_segments = 96 checkpoint_timeout = 10min
>
>> I bet you'll see noticeably - while still not great - better
>> performanc
Andres Freund writes:
> On 2014-04-14 14:33:03 -0700, Joe Conway wrote:
>> checkpoint_segments = 96
>> checkpoint_timeout = 10min
> I bet you'll see noticeably - while still not great - better performance
> by setting checkpoint_timeout to an hour (with a corresponding increase
> in checkpoint_se
On 4/14/14, 5:51 PM, Joe Conway wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/14/2014 03:17 PM, Jim Nasby wrote:
On 4/14/14, 4:50 PM, Andres Freund wrote:
On 2014-04-14 14:33:03 -0700, Joe Conway wrote:
I realize there are many things that can be done to improve my
specific scena
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/14/2014 03:17 PM, Jim Nasby wrote:
> On 4/14/14, 4:50 PM, Andres Freund wrote:
>> On 2014-04-14 14:33:03 -0700, Joe Conway wrote:
>>> I realize there are many things that can be done to improve my
>>> specific scenario, e.g. drop indexes before
On 4/14/14, 4:50 PM, Andres Freund wrote:
Hi,
On 2014-04-14 14:33:03 -0700, Joe Conway wrote:
checkpoint_segments = 96
checkpoint_timeout = 10min
I realize there are many things that can be done to improve my
specific scenario, e.g. drop indexes before loading, change various
configs, etc. M
Hi,
On 2014-04-14 14:33:03 -0700, Joe Conway wrote:
> checkpoint_segments = 96
> checkpoint_timeout = 10min
> I realize there are many things that can be done to improve my
> specific scenario, e.g. drop indexes before loading, change various
> configs, etc. My purpose for this post is to ask if
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I have run into a situation where bulk loading a table with fairly
narrow rows and two indexes causes WAL to be generated at about 20:1
or higher ratio to the actual heap data (table plus indexes).
There are 560 million loaded rows which ultimately pr
15 matches
Mail list logo
