Re: Re: patch: fix performance problems with repated decomprimation of varlena values in plpgsql
От | Tom Lane |
---|---|
Тема | Re: Re: patch: fix performance problems with repated decomprimation of varlena values in plpgsql |
Дата | |
Msg-id | 25445.1295970470@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Re: patch: fix performance problems with repated decomprimation of varlena values in plpgsql (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Re: patch: fix performance problems with repated
decomprimation of varlena values in plpgsql
Re: Re: patch: fix performance problems with repated decomprimation of varlena values in plpgsql |
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > On Tue, Jan 25, 2011 at 10:03 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> The arguments that were made against this were about maintenance costs >> and code footprint. �Claims about performance are not really relevant, >> especially when they're entirely unsupported by evidence. > How much evidence do you need to the effect that detoasting a value > that's never used will hurt performance? I agree that at some microscopic level it will cost something. What's not been shown is that there's any significant cost in any real-world use pattern. As Pavel said upthread, the main thing here is to get rid of cases where there are many many repeated detoastings. Adding an occasional detoast that wouldn't have happened before is a good tradeoff for that. To convince me that we should contort the code to go further, you need to show that that's more than a negligible cost. regards, tom lane
В списке pgsql-hackers по дате отправления: