From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Joe Conway <mail(at)joeconway(dot)com> |
Cc: | Bertrand Petit <elrond(at)phoe(dot)frmug(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: 7.4 beta 1 getting out of swap |
Date: | 2003-08-15 11:09:58 |
Message-ID: | 12303.1060945798@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-performance |
Joe Conway <mail(at)joeconway(dot)com> writes:
> Tom Lane wrote:
>> 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.
> It seems to me that #3 is the least risky, and even if it isn't the best
> possible performance, this is the initial implementation of indexes on
> arrays, so it isn't like we're taking away something. Maybe solution #2
> is better held as a performance enhancement for 7.5.
I'm leaning that way too. It occurs to me also that the same cache
could be used to eliminate repeated lookups in sorting setup --- which
would not be much of a win percentagewise, compared to the sort itself,
but still it seems worth doing.
> Do you want me to take a shot at this since I created the mess?
Actually I led you down the garden path on that, IIRC --- I was the one
who insisted these lookups needed to be cached. I'll work on fixing it.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-08-15 11:51:54 | ADD FOREIGN KEY (was Re: [GENERAL] 7.4Beta) |
Previous Message | Tom Lane | 2003-08-15 10:57:24 | Re: New function: epoch_to_timestamp... |
From | Date | Subject | |
---|---|---|---|
Next Message | Richard Huxton | 2003-08-15 13:12:08 | Re: Benchmark |
Previous Message | Toni Schlichting | 2003-08-15 10:06:04 | Re: On Linux Filesystems |