On Tue, Sep 19, 2017 at 8:48 AM, Kyotaro HORIGUCHI
wrote:
> Though a bit uneasy to have similar code on both side
> (XLogBackgroundFlush and XLogSetAsyncXactLSN) but +1 to this from
> me.
This patch wasn't formatted very nicely; attached is a version that
pgindent likes better and doesn't bust pa
At Sat, 26 Aug 2017 14:45:20 -0700, Jeff Janes wrote in
> On Mon, Jul 3, 2017 at 8:26 PM, Jeff Janes wrote:
>
> > On Sat, Jun 24, 2017 at 5:09 PM, Andres Freund wrote:
> >
> >> On 2017-06-15 15:06:43 -0700, Jeff Janes wrote:
> >>
> >>
> >>
> >
> >> > Wouldn't it
> >> > better, and much simple
On Mon, Jul 3, 2017 at 8:26 PM, Jeff Janes wrote:
> On Sat, Jun 24, 2017 at 5:09 PM, Andres Freund wrote:
>
>> On 2017-06-15 15:06:43 -0700, Jeff Janes wrote:
>>
>>
>>
>
>> > Wouldn't it
>> > better, and much simpler, just to have reverted the first change once
>> the
>> > second one was done?
>
On Mon, Jul 3, 2017 at 11:26 PM, Jeff Janes wrote:
> My understanding is that you can't start on a new file until the old file is
> completely synced, because the book keeping can currently only handle one
> file at a time. So if you signal the wal writer to do the sync, you would
> just end up i
On Sat, Jun 24, 2017 at 5:09 PM, Andres Freund wrote:
> Hi,
>
> On 2017-06-15 15:06:43 -0700, Jeff Janes wrote:
>
> > It looks like only limited consolidation was happening, the number of
> kills
> > invoked was more than half of the number of SetLatch. I think the reason
> > is what when kill(o
Hi,
On 2017-06-15 15:06:43 -0700, Jeff Janes wrote:
> > Well, wal_writer_delay doesn't work if walwriter is in sleep mode, and
> > this afaics would allow wal writer to go into sleep mode with half a
> > page filled, and it'd not be woken up again until the page is filled.
> > No?
> >
>
> If it i
On Thu, Jun 15, 2017 at 3:06 PM, Jeff Janes wrote:
>
> This new patch is simpler than the previous one, and more effective at
> speeding up replication. I assume it would speed up pgbench with
> synchronous_commit turned off (or against unlogged tables) as well, but I
> don't think I have the har
On Wed, Jun 14, 2017 at 4:29 PM, Andres Freund wrote:
> On 2017-06-14 16:24:27 -0700, Jeff Janes wrote:
> > On Wed, Jun 14, 2017 at 3:20 PM, Andres Freund
> wrote:
> >
> > > On 2017-06-14 15:08:49 -0700, Jeff Janes wrote:
> > > > On Wed, Jun 14, 2017 at 11:55 AM, Jeff Janes
> > > wrote:
> > > >
On 2017-06-14 16:24:27 -0700, Jeff Janes wrote:
> On Wed, Jun 14, 2017 at 3:20 PM, Andres Freund wrote:
>
> > On 2017-06-14 15:08:49 -0700, Jeff Janes wrote:
> > > On Wed, Jun 14, 2017 at 11:55 AM, Jeff Janes
> > wrote:
> > >
> > > > If I publish a pgbench workload and subscribe to it, the subsc
On Wed, Jun 14, 2017 at 3:20 PM, Andres Freund wrote:
> On 2017-06-14 15:08:49 -0700, Jeff Janes wrote:
> > On Wed, Jun 14, 2017 at 11:55 AM, Jeff Janes
> wrote:
> >
> > > If I publish a pgbench workload and subscribe to it, the subscription
> > > worker is signalling the wal writer thousands of
On 2017-06-14 15:08:49 -0700, Jeff Janes wrote:
> On Wed, Jun 14, 2017 at 11:55 AM, Jeff Janes wrote:
>
> > If I publish a pgbench workload and subscribe to it, the subscription
> > worker is signalling the wal writer thousands of times a second, once for
> > every async commit. This has a notic
On Wed, Jun 14, 2017 at 11:55 AM, Jeff Janes wrote:
> If I publish a pgbench workload and subscribe to it, the subscription
> worker is signalling the wal writer thousands of times a second, once for
> every async commit. This has a noticeable performance cost.
>
I've used a local variable to a
If I publish a pgbench workload and subscribe to it, the subscription
worker is signalling the wal writer thousands of times a second, once for
every async commit. This has a noticeable performance cost.
I don't think it is ever necessary to signal the wal writer here, unless
wal writer is taking
13 matches
Mail list logo
