Do you know the reason for increased max latency due to xlog scaling?

From: "MauMau" <maumau307(at)gmail(dot)com>
To: "Heikki Linnakangas" <hlinnakangas(at)vmware(dot)com>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Do you know the reason for increased max latency due to xlog scaling?
Date: 2014-02-17 15:43:54
Message-ID: 14B45CC96F564D2FA369A4C6D7FB64D9@maumau
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello Heikki san,

I'm excited about your great work, xlog scaling. I'm looking forward to the
release of 9.4.

Please let me ask you about your performance data on the page:

http://hlinnaka.iki.fi/xloginsert-scaling/padding/

I'm worried about the big increase in max latency. Do you know the cause?
More frequent checkpoints caused by increased WAL volume thanks to enhanced
performance?

Although I'm not sure this is related to what I'm asking, the following code
fragment in WALInsertSlotAcquireOne() catched my eyes. Shouldn't the if
condition be "slotno == -1" instead of "!="? I thought this part wants to
make inserters to use another slot on the next insertion, when they fail to
acquire the slot immediately. Inserters pass slotno == -1. I'm sorry if I
misunderstood the code.

/*
* If we couldn't get the slot immediately, try another slot next time.
* On a system with more insertion slots than concurrent inserters, this
* causes all the inserters to eventually migrate to a slot that no-one
* else is using. On a system with more inserters than slots, it still
* causes the inserters to be distributed quite evenly across the slots.
*/
if (slotno != -1 && retry)
slotToTry = (slotToTry + 1) % num_xloginsert_slots;

Regards
MauMau

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2014-02-17 15:50:16 Re: Decimal values in
Previous Message Andres Freund 2014-02-17 15:26:46 Re: narwhal and PGDLLIMPORT