Skip site navigation (1) Skip section navigation (2)

Re: TupleDesc refcounting

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Neil Conway <neilc(at)samurai(dot)com>
Cc: pgsql-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: TupleDesc refcounting
Date: 2006-06-16 18:50:48
Message-ID: 28317.1150483848@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-patches
I wrote:
> I'm finally getting back to looking at the problem of reference-counting
> cached TupleDescs as was discussed in January.  I had objected to the
> last patch Neil posted:
> http://archives.postgresql.org/pgsql-patches/2006-01/msg00243.php
> on the grounds that it seemed too complicated.  On looking at it
> closely, I realize that a lot of the complexity comes from my insistence
> that the ResourceOwner mechanism ought to warn about any tupdesc
> references that haven't been explicitly released before transaction end.

After much thrashing I concluded that my original instinct was right and
we really do want to insist on cleanup of tupdesc references during
normal processing.  The approach I tried to take effectively meant
leaking tupdesc references until end of query, which is really bad news
for SQL-language functions --- a function that grabs a tupdesc reference
during plan startup would then accumulate a tupdesc reference during
every invocation, leading to indefinite bloat in the ResourceOwner over
a long query.

So I ended up applying something pretty close to Neil's patch.  I did
modify it to not bother reference-counting tupdescs that aren't actually
in any cache.  I also fixed up TupleTableSlots to do reference-count
processing if ExecSetSlotDescriptor is handed a reference-counted
tupdesc (my assertion yesterday that this never happens was wrong),
but not to bother cleaning up non-ref-counted descriptors.

All in all, a lot of thrashing for only marginal improvement :-(

			regards, tom lane

In response to

pgsql-patches by date

Next:From: Bruce MomjianDate: 2006-06-16 20:05:21
Subject: Re: [Win32] Problem with rename()
Previous:From: Bruce MomjianDate: 2006-06-16 18:48:59
Subject: Re: [HACKERS] Automatic free space map filling

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group