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

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
Cc: Ildar Musin <i.musin@postgrespro.ru>
Cc: pgsql-hackers@postgresql.org
Subject: Re: Declarative partitioning
Date: Wed, 18 May 2016 13:48:59 -0400
Message-ID: <14105.1463593739@sss.pgh.pa.us> (raw)
In-Reply-To: <573BC4DB.2040507@lab.ntt.co.jp>
References: <55D3093C.5010800@lab.ntt.co.jp>
	<CADkLM=cb7q4TSYQYX4EsMHVK0hjEnBJiA8+XMSSropk2CHwa_A@mail.gmail.com>
	<56DF74F0.7060404@lab.ntt.co.jp>
	<CAPpHfdut34uqoY1vKgvBhsGZqhR6Nky=_Dxn0un57G_M2CvLTA@mail.gmail.com>
	<CA+HiwqFFH10_ku6z_Ps=H7=pR5cWJk9Bdr9nE08+3F53yTEr9A@mail.gmail.com>
	<CAPpHfdu0mGbt9T2Jx04OKJfJQ0zW55BFqmisinRYWd2OaowRWQ@mail.gmail.com>
	<CA+TgmoaoZRqk2dr3xonta3o4omKuO4V4niVC2DKKo9VpdMc_zQ@mail.gmail.com>
	<56F0AC96.2010303@lab.ntt.co.jp>
	<CAFjFpReZ2nmpfOA2uGdgVp3ivWC13VDFYOQ7rs5LFeqo_Zm4vA@mail.gmail.com>
	<57106F9E.3000309@lab.ntt.co.jp>
	<57163954.2020701@postgrespro.ru>
	<CAPpHfdtH4rhckHzkqGhGP8O7aejj=J7_qJRA3dTu+iAUpuzPgg@mail.gmail.com>
	<CA+HiwqEMQ2EZ0GKBjg2hHT1uP-NRodtodc2JjN1vd0xp_BzTCg@mail.gmail.com>
	<571759D8.7030205@lab.ntt.co.jp>
	<57179653.30905@postgrespro.ru>
	<CA+HiwqF=0v6afwGj=Fc3gBF94Wp65naJUiDt6sFQiNXvtsFXSg@mail.gmail.com>
	<57183572.8020900@lab.ntt.co.jp>
	<5739C742.80504@postgrespro.ru>
	<573ACEB2.1090705@lab.ntt.c! o.jp>
	<1404.1463505762@sss.pgh.! pa.us>
	<573BC4DB.2040507@lab.ntt.co.jp>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>

Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> writes:
> On 2016/05/18 2:22, Tom Lane wrote:
>> The two ways that we've dealt with this type of hazard are to copy data
>> out of the relcache before using it; or to give the relcache the
>> responsibility of not moving a particular portion of data if it did not
>> change.  From memory, the latter applies to the tuple descriptor and
>> trigger data, but we've done most other things the first way.

After actually looking at the code, we do things that way for the
tupledesc, the relation's rules if any, and RLS policies --- see
RelationClearRelation().

> It seems that tuple descriptor is reference-counted; however trigger data
> is copied.  The former seems to have been done on performance grounds (I
> found 06e10abc).

We do refcount tuple descriptors, but we've been afraid to try to rely
completely on that; there are too many places that assume a relcache
entry's tupdesc is safe to reference.  It's not that easy to go over to
a fully refcounted approach, because that creates a new problem of being
sure that refcounts are decremented when necessary --- that's a pain,
particularly when a query is abandoned due to an error.

> So for a performance-sensitive relcache data structure, refcounting is the
> way to go (although done quite rarely)?

I'd be suspicious of this because of the cleanup problem.  The
don't-replace-unless-changed approach is the one that's actually battle
tested.

			regards, tom lane


-- 
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 (161+ messages)  latest in thread

Message-ID: <14105.1463593739@sss.pgh.pa.us>
Permalink:  ../14105.1463593739@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/14105.1463593739@sss.pgh.pa.us

 · 

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: tgl@sss.pgh.pa.us, Langote_Amit_f8@lab.ntt.co.jp, i.musin@postgrespro.ru
  Subject: Re: Declarative partitioning
  In-Reply-To: <14105.1463593739@sss.pgh.pa.us>

* 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