Re: 7.4 beta 1 getting out of swap

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bertrand Petit <elrond(at)phoe(dot)frmug(dot)org>, Joe Conway <mail(at)joeconway(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: 7.4 beta 1 getting out of swap
Date: 2003-08-15 00:41:52
Message-ID: 200308150041.h7F0fqn08208@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance

> I can think of a number of ways we might attack this, but none seem
> especially attractive ---
>
> 1. Have the index AMs create and switch into a special memory context
> for each call, rather than running in the main execution context.
> I am not sure this is workable at all, since the AMs tend to think they
> can create data structures that will live across calls (for example a
> btree lookup stack). It'd be the most general solution, if we could
> make it work.
>
> 2. Modify the index AMs so that the comparison function FmgrInfo is
> preserved across a whole query. I think this requires changes to the
> index AM API (index_insert for instance has no provision for sharing
> data across multiple calls). Messy, and would likely mean an initdb.
> It would probably be the fastest answer though, since lookups wouldn't
> need to be done more than once per query.

#2 seems most natural in that it formalizes something that is common for
lots of index methods.

We are only in beta1, so I think we can initdb.

> 3. Set up a long-lived cache internal to the array functions that can
> translate element type OID to the needed lookup data, and won't leak
> memory across repeated calls. This is not the fastest or most general
> solution, but it seems the most localized and safest fix.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Christopher Kings-Lynne 2003-08-15 02:12:25 Re: New function: epoch_to_timestamp...
Previous Message Tom Lane 2003-08-15 00:17:50 Re: 7.4 beta 1 getting out of swap

Browse pgsql-performance by date

  From Date Subject
Next Message Joe Conway 2003-08-15 02:46:20 Re: 7.4 beta 1 getting out of swap
Previous Message Tom Lane 2003-08-15 00:17:50 Re: 7.4 beta 1 getting out of swap