pg.ddx.io pgsql-hackers@postgresql.org mailing list archive help / color / mirror / Atom feed From: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Ildar Musin <i.musin@postgrespro.ru>
Cc: pgsql-hackers@postgresql.org
Subject: Re: Declarative partitioning
Date: Thu, 19 May 2016 19:29:33 +0900
Message-ID: <573D958D.4040308@lab.ntt.co.jp> (raw )
In-Reply-To: <14105.1463593739@sss.pgh.pa.us >
References: <55D3093C.5010800@lab.ntt.co.jp >
<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 >
<14105.1463593739@sss.pgh.pa.us >
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
On 2016/05/19 2:48, Tom Lane wrote:
> 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().
I think I confused refcounting method of keeping things around with the
RelationClearRelation()'s method. I now understand that you meant the
latter in your original message.
>> 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.
I see.
>> 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.
OK, I will try the RelationClearRelation()'s method of keeping partition
descriptor data around so that no repeated copying is necessary.
Thanks,
Amit
--
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: <573D958D.4040308@lab.ntt.co.jp>
Permalink: ../573D958D.4040308@lab.ntt.co.jp/
Also on: postgresql.org/message-id/573D958D.4040308@lab.ntt.co.jp
copy link · copy postgr.es
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: Langote_Amit_f8@lab.ntt.co.jp, tgl@sss.pgh.pa.us, i.musin@postgrespro.ru
Subject: Re: Declarative partitioning
In-Reply-To: <573D958D.4040308@lab.ntt.co.jp>
* 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