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 <amitlangote09@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: unsupportable composite type partition keys
Date: Wed, 25 Dec 2019 00:31:01 -0500
Message-ID: <15619.1577251861@sss.pgh.pa.us> (raw)
In-Reply-To: <CA+HiwqH7HKEa+bUpF2pSWpRRZV6E0v5YxLWRW2gBQ=WYw8L5oQ@mail.gmail.com>
References: <CA+HiwqFUzjfj9HEsJtYWcr1SgQ_=iCAvQ=O2Sx6aQxoDu4OiHw@mail.gmail.com>
	<5361.1576602769@sss.pgh.pa.us>
	<CA+HiwqGiGBgFFcL6YGKRqfX1-gYKmuLLG_JwU_UaSaX2J+jehQ@mail.gmail.com>
	<28160.1576676326@sss.pgh.pa.us>
	<CA+HiwqENLY2ta0goA0jcfk4cWdj2W0r6Ywjf=PQiMpJkyXygmg@mail.gmail.com>
	<26766.1576947735@sss.pgh.pa.us>
	<24653.1576962784@sss.pgh.pa.us>
	<CA+HiwqGug69_zhRCzENJPg_Ynpx_Eb-2-=N1u2Zw3X6T1S3wbQ@mail.gmail.com>
	<25383.1577112556@sss.pgh.pa.us>
	<CA+HiwqFBwbmkqvKM-CmoK6yOcokwWcOzjz-fP1O317qn8kgGEA@mail.gmail.com>
	<20151.1577127467@sss.pgh.pa.us>
	<9214.1577136835@sss.pgh.pa.us>
	<CA+HiwqHoNKn3HBb0yZ9sCZu=GL_KxrXAFiYygLTgS95DBOcZTw@mail.gmail.com>
	<CA+HiwqH7HKEa+bUpF2pSWpRRZV6E0v5YxLWRW2gBQ=WYw8L5oQ@mail.gmail.com>

Amit Langote <amitlangote09@gmail.com> writes:
> On Tue, Dec 24, 2019 at 10:59 AM Amit Langote <amitlangote09@gmail.com> wrote:
>> Btw, does the memory leakage fix in this patch address any of the
>> pending concerns that were discussed on the "hyrax vs.
>> RelationBuildPartitionDesc" thread earlier this year[1]?
>> [1] https://www.postgresql.org/message-id/flat/3800.1560366716%40sss.pgh.pa.us#092b6b4f6bf75d2f3f90ef6a3...

> I thought about this a little and I think it *does* address the main
> complaint in the above thread.

I experimented with the test shown in [1].  This patch does prevent that
case from accumulating copies of the partition descriptor.

(The performance of that test case is still awful, more or less O(N^2)
in the number of repetitions.  But I think what's going on is that it
repeatedly creates and deletes the same catalog entries, and we're not
smart enough to recognize that the dead row versions are fully dead,
so lots of time is wasted by unique-index checks.  It's not clear
that that's of any interest for real-world cases.)

I remain of the opinion that this is a pretty crummy, ad-hoc way to manage
the partition descriptor caching.  It's less bad than before, but I'm
still concerned that holding a relcache entry open for any long period
could result in bloat if the cache entry is rebuilt many times meanwhile
--- and there's no strong reason to think that can't happen.  Still,
maybe we can wait to solve that until there's some evidence that it
does happen in useful cases.

I also poked at the test case mentioned in the other thread about foreign
keys across lots of partitions [2].  Again, this patch gets rid of the
memory bloat, though the performance is still pretty awful with lots of
partitions for other reasons.

			regards, tom lane

[1] https://www.postgresql.org/message-id/10797.1552679128%40sss.pgh.pa.us
[2] https://www.postgresql.org/message-id/OSAPR01MB374809E8DE169C8BF2B82CBD9F6B0%40OSAPR01MB3748.jpnprd0...





view thread (31+ messages)  latest in thread

Message-ID: <15619.1577251861@sss.pgh.pa.us>
Permalink:  ../15619.1577251861@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/15619.1577251861@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, amitlangote09@gmail.com, pgsql-hackers@lists.postgresql.org
  Subject: Re: unsupportable composite type partition keys
  In-Reply-To: <15619.1577251861@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