Received: from magus.postgresql.org (magus.postgresql.org [87.238.57.229])
	by mail.postgresql.org (Postfix) with ESMTP id 4B392F6332D
	for <pgsql-hackers@postgresql.org>;
	Thu, 19 Jul 2012 18:02:27 -0300 (ADT)
Received: from sss.pgh.pa.us ([66.207.139.130])
	by magus.postgresql.org with esmtp (Exim 4.72)
	(envelope-from <tgl@sss.pgh.pa.us>) id 1Srxrd-00079t-3R
	for pgsql-hackers@postgresql.org; Thu, 19 Jul 2012 21:02:26 +0000
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.14.5/8.14.5) with ESMTP id q6JL28XE013266;
	Thu, 19 Jul 2012 17:02:08 -0400 (EDT)
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
cc: Jeff Janes <jeff.janes@gmail.com>,
	pgsql-hackers <pgsql-hackers@postgresql.org>,
	Daniel Farina <daniel@heroku.com>, Craig Ringer <ringerc@ringerc.id.au>,
	=?ISO-8859-1?Q?Harold_A=2E_Gim=E9nez?= <harold.gimenez@gmail.com>
Subject: Re: [PERFORM] DELETE vs TRUNCATE explanation
In-reply-to: 
 <CA+TgmobkLaBJa5+HG9VsV_MNJGiVEBymio-msdKETZiPk1q36Q@mail.gmail.com>
References: <4FFCCAC4.4030503@ringerc.id.au>
	<CAAZKuFZ9tYeC1K5ZayZgztm3re_7ytbsEYFa0wwXirB6Hfm+EQ@mail.gmail.com>
	<23853.1342015548@sss.pgh.pa.us>
	<CAAZKuFYsK+ZQuC=zf0xE=M-LNa02tB7RBy3CHEUyq7LWCkK6jQ@mail.gmail.com>
	<CAMkU=1ydaypgAeZxyaMc=KhJJw5riGMBiLpvSqOO42=qArRZmQ@mail.gmail.com>
	<32078D4B40DD40ECB739D0ECD7D95996@gmail.com>
	<CAMkU=1zJK6WiS9-6eO8rNmRpKSSB4=uw2mTsD=k64mNh__=Dcg@mail.gmail.com>
	<CAMkU=1w7vLA63hf-+Uc_j61CvOdKixsOHph9d0H-aLNBYgfX=w@mail.gmail.com>
	<CAMkU=1yLXvODRZZ_=fgrEeJfk2tvZPTTD-8n8BwrAhNz_WBT0A@mail.gmail.com>
	<19949.1342376967@sss.pgh.pa.us>
	<CA+TgmoaTf=zjP37-oG7fr1VbGfuvHSfpajgLZ65EeSJX2mmquA@mail.gmail.com>
	<9603.1342454919@sss.pgh.pa.us>
	<CA+Tgmoa4ta60Y-rZpEPDRCQKJV8-Uqe0P610Jgj2q7e+fondig@mail.gmail.com>
	<11952.1342456591@sss.pgh.pa.us>
	<CA+TgmoYRXMWQ_DGmmqu3Zp8oW3Lt-9Lc1q3EHaV_ZmjWqaPkuA@mail.gmail.com>
	<2358.1342646246@sss.pgh.pa.us>
	<CA+TgmoYg1t3jAOVQLwiCCG6eNcJ8DbVdi_3Vfr=-8-cvxm3zag@mail.gmail.com>
	<20408.1342706966@sss.pgh.pa.us> <CA+TgmoagwPY!
	G8QO3ykccp4_dpYy_Y_KKzF4QQB
	<CA+TgmobkLaBJa5+HG9VsV_MNJGiVEBymio-msdKETZiPk1q36Q@mail.gmail.com>
Comments: In-reply-to Robert Haas <robertmhaas@gmail.com>
	message dated "Thu, 19 Jul 2012 16:03:20 -0400"
Date: Thu, 19 Jul 2012 17:02:08 -0400
Message-ID: <13265.1342731728@sss.pgh.pa.us>
X-Pg-Spam-Score: -1.9 (-)
X-Archive-Number: 201207/841
X-Sequence-Number: 211524

Robert Haas <robertmhaas@gmail.com> writes:
> What if we change the hash table to have RelFileNode as the key and an
> array of MAX_FORKNUM bitmapsets as the value?  Then when you get a
> "forget" request, you can just zap all the sets to empty.

Hm ... the only argument I can really make against that is that there'll
be no way to move such a table into shared memory; but there's probably
little hope of that anyway, given points made upthread.  The bitmapset
manipulations are a bit tricky but solvable, and I agree there's
something to be said for not tying this stuff so closely to the
mechanism for relfilenode recycling.

			regards, tom lane