Re: Re: patch: fix performance problems with repated decomprimation of varlena values in plpgsql - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Re: patch: fix performance problems with repated decomprimation of varlena values in plpgsql
Date
Msg-id 27127.1295471934@sss.pgh.pa.us
Whole thread Raw
In response to Re: Re: patch: fix performance problems with repated decomprimation of varlena values in plpgsql  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Responses Re: Re: patch: fix performance problems with repated decomprimation of varlena values in plpgsql  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> If we could solve the refcounting problem I think this would be a
>> very significant win.
> Instead of trying to keep a refcount, how about just evicting from
> the buffer as needed based on LRU?

Well, unless you know for certain that an item is no longer used, you
can't evict it.  There are ways you could finesse that --- for instance,
you might try to only flush between statements, when certainly no user
functions are running --- but the problem is that the cache is likely
to contain some large values that you can't adopt such a laissez faire
approach with, or you'll run out of memory.

One idea that I think we discussed was to tie cache entries to the
memory context they were demanded in, and mark them unused at the next
context reset/delete.  That way they'd be considered unused at the same
points where the current implementation would certainly have discarded
the value.  This isn't perfect (because of pfree) but might be good
enough.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Thom Brown
Date:
Subject: Re: Couple document fixes
Next
From: Robert Haas
Date:
Subject: Re: Re: patch: fix performance problems with repated decomprimation of varlena values in plpgsql