pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Jim Nasby <Jim.Nasby@BlueTreble.com>
To: Amit Kapila <amit.kapila16@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: David Steele <david@pgmasters.net>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Thom Brown <thom@linux.com>
Cc: Simon Riggs <simon@2ndquadrant.com>
Cc: Jesper Pedersen <jesper.pedersen@redhat.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: Speed up Clog Access by increasing CLOG buffers
Date: Tue, 22 Mar 2016 22:21:19 -0500
Message-ID: <56F20BAF.10803@BlueTreble.com> (raw)
In-Reply-To: <CAA4eK1K9Z5L8rBu6nAk55oSTE4iC_aw=d+MyqpEy4UL6=aTG8w@mail.gmail.com>
References: <CAA4eK1J70Aj6Pvt31LYMD8ptMv7+9WFN0cQLq1LGhCYPFM9njw@mail.gmail.com>
	<CA+Tgmobf5PFpoi3w4zwf5DS0DzwYYpWzHDwwHmQw5Xto1dKyOg@mail.gmail.com>
	<CAA4eK1+dic2HZiqMf4o0O4acUP88R-5-A-9kXU9uz3COOW2WiA@mail.gmail.com>
	<CA+TgmobTdYgh24XNHMoGansYn=zCH5WzAg58jAeNA8WEVUbrbA@mail.gmail.com>
	<CAA4eK1L4iV-2qe7AyMVsb+nz7SiX8JvCO+CqhXwaiXgm3CaBUw@mail.gmail.com>
	<CAA4eK1KZ1HVOjy39i3FRS9MsbR6GgH8D7cqyoYJxyb2PJt05Qg@mail.gmail.com>
	<56E7032D.6060908@pgmasters.net>
	<CAA4eK1LGgOyn9OpiK8W3PfrXqfHsvTi0hy0y00bu50YfE_X+MA@mail.gmail.com>
	<20160322105221.GD3790@awork2.anarazel.de>
	<CAA4eK1+pWLPZGD6xYfJP=M6WHHzES-yyYSA4qpCA-jy0npKSUw@mail.gmail.com>
	<20160322125957.GH3790@awork2.anarazel.de>
	<CAA4eK1K9Z5L8rBu6nAk55oSTE4iC_aw=d+MyqpEy4UL6=aTG8w@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>

On 3/22/16 9:36 AM, Amit Kapila wrote:
>  > > Note, that we are doing it only when a transaction has less than
> equal to
>  > > 64 sub transactions.
>  >
>  > So?
>  >
>
> They should fall on one page, unless they are heavily interleaved as
> pointed by you.  I think either subtransactions are present or not, this
> patch won't help for bigger transactions.

FWIW, the use case that comes to mind here is the "upsert" example in 
the docs. AFAIK that's going to create a subtransaction every time it's 
called, regardless if whether it performs actual DML. I've used that in 
places that would probably have moderately high concurrency, and I 
suspect I'm not alone in that.

That said, it wouldn't surprise me if plpgsql overhead swamps an effect 
this patch has, so perhaps it's a moot point.
-- 
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers



view thread (248+ messages)  latest in thread

Message-ID: <56F20BAF.10803@BlueTreble.com>
Permalink:  ../56F20BAF.10803@BlueTreble.com/
Also on:    postgresql.org/message-id/56F20BAF.10803@BlueTreble.com

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: Jim.Nasby@BlueTreble.com, amit.kapila16@gmail.com, andres@anarazel.de, david@pgmasters.net, robertmhaas@gmail.com, thom@linux.com, simon@2ndquadrant.com, jesper.pedersen@redhat.com
  Subject: Re: Speed up Clog Access by increasing CLOG buffers
  In-Reply-To: <56F20BAF.10803@BlueTreble.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox