Re: hyrax vs. RelationBuildPartitionDesc

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: hyrax vs. RelationBuildPartitionDesc
Date: 2019-03-15 18:39:54
Message-ID: CA+TgmoYMoUDQH7kGqbEUDBJkcr-G_Di6pu04uL6UPexgcodF0Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Mar 15, 2019 at 2:18 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> BTW, after closer study of 898e5e329 I have a theory as to why it
> made things worse for CCA animals: it causes relcache entries to be
> held open (via incremented refcounts) throughout planning, which
> they were not before. This means that, during each of the many
> RelationCacheInvalidate events that will occur during a planning
> cycle, we have to rebuild those relcache entries; previously they
> were just dropped once and that was the end of it till execution.

That makes sense. Thanks for looking at it, and for the insight.

> You noted correctly that the existing PartitionDesc structure would
> generally get preserved during each reload --- but that has exactly
> zip to do with the amount of transient space consumed by execution
> of RelationBuildDesc. We still build a transient PartitionDesc
> that we then elect not to install. And besides that there's all the
> not-partitioning-related stuff that RelationBuildDesc can leak.

Right. So it's just that we turned a bunch of rebuild = false
situations into rebuild = true situations. I think.

> This is probably largely irrelevant for non-CCA situations, since
> we don't expect forced relcache invals to occur often otherwise.
> But it seems to fit the facts, particularly that hyrax is only dying
> on queries that involve moderately large partitioning structures
> and hence quite a few relations pinned by PartitionDirectory entries.
>
> I remain of the opinion that we ought not have PartitionDirectories
> pinning relcache entries ... but this particular effect isn't really
> significant to that argument, I think.

Cool. I would still like to hear more about why you think that. I
agree that the pinning is not great, but copying moderately large
partitioning structures that are only likely to get more complex in
future releases also does not seem great, so I think it may be the
least of evils. You, on the other hand, seem to have a rather
visceral hatred for it. That may be based on facts with which I am
not acquainted or it may be that we have a different view of what good
design looks like. If it's the latter, we may just have to agree to
disagree and see if other people want to opine, but if it's the
former, I'd like to know those facts.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Janes 2019-03-15 19:20:06 Re: GiST VACUUM
Previous Message Andrey Borodin 2019-03-15 18:25:27 Re: GiST VACUUM