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: Ildar Musin <i.musin@postgrespro.ru>
To: pgsql-hackers@postgresql.org
Subject: Re: Declarative partitioning
Date: Tue, 17 May 2016 16:56:34 +0900
Message-ID: <573ACEB2.1090705@lab.ntt.co.jp> (raw )
In-Reply-To: <5739C742.80504@postgrespro.ru >
References: <55D3093C.5010800@lab.ntt.co.jp >
<56DE2D4B.1040001@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 >
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
Hi Ildar,
On 2016/05/16 22:12, Ildar Musin wrote:
> Hi Amit,
>
> I'm running some experiments based on your infrastructure trying to
> optimize SELECT queries. At some point I need to get PartitionDesc for
> relation and to do it I'm using RelationGetPartitionDesc() function.
> Problem is that this function copies relcache data and it can be quite
> slow for large amounts (thousands) of partitions. The comment to the
> function says that we cannot use relation->rd_partdesc pointer to relcache
> because of possibility of relcache invalidation. Could you please tell is
> it possible that relcache invalidation occurs during SELECT/UPDATE/DELETE
> query?
Hmm, I think invalidation would not occur mid-query since it would have
acquired a lock on the table. So the copying may be unnecessary though I
may be wrong. I will study other similar code and see if that is so.
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: <573ACEB2.1090705@lab.ntt.co.jp>
Permalink: ../573ACEB2.1090705@lab.ntt.co.jp/
Also on: postgresql.org/message-id/573ACEB2.1090705@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, i.musin@postgrespro.ru
Subject: Re: Declarative partitioning
In-Reply-To: <573ACEB2.1090705@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