Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de [53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id NAA90560 for ; Mon, 3 Jan 2000 13:35:31 -0500 (EST) (envelope-from wieck@debis.com) Received: from debis.com by orion.SAPserv.Hamburg.dsh.de with smtp for id m125CAE-0003kGC; Mon, 3 Jan 100 19:25 MET Sender: wieck Message-ID: <3870E982.B123DF8A@debis.com> Date: Mon, 03 Jan 2000 19:25:06 +0100 From: Jan Wieck X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.9 i686) X-Accept-Language: en MIME-Version: 1.0 To: Tom Lane CC: Bruce Momjian , pgsql-hackers@postgreSQL.org Subject: Index toasting (was: Re: [HACKERS] Error "vacuum pg_proc") References: <199912270336.WAA28667@candle.pha.pa.us> <25243.946268065@sss.pgh.pa.us> <25283.946268363@sss.pgh.pa.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Tom Lane wrote: > I wrote: > > And that'll still crash and burn for multicolumn indexes. > > Not to mention functional indexes, which typically store values that > don't appear in the referenced tuple at all. > > Basically, indexes have to have their own toasters. There's no other > way. You're right. I think it's best to delay index toasting until we have some experience with normal, main tuple attribute toasting. It'd be nice if the solution had covered huge values to be indexed automatically (what it doesn't any more). But I think most people can live with a database, that cannot index huge values, but is capable to store and retrieve them for now. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #========================================= wieck@debis.com (Jan Wieck) #