Re: Re: patch: fix performance problems with repated decomprimation of varlena values in plpgsql
От | Robert Haas |
---|---|
Тема | Re: Re: patch: fix performance problems with repated decomprimation of varlena values in plpgsql |
Дата | |
Msg-id | AANLkTin61EuaMEytKaA6pTs+5zHq0k62RLy3axQAwjpe@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Re: patch: fix performance problems with repated decomprimation of varlena values in plpgsql (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Re: patch: fix performance problems with repated decomprimation of varlena values in plpgsql
|
Список | pgsql-hackers |
On Wed, Jan 19, 2011 at 12:10 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Tue, Jan 18, 2011 at 5:22 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote: >>> opinion isn't strong in this topic. One or twenty useless detoasting >>> isn't really significant in almost use cases (problem is thousands >>> detoasting). > >> Yeah. Many-times-repeated detoasting is really bad, and this is not >> the only place in the backend where we have this problem. :-( > > Yeah, there's been some discussion of a more general solution, and I > think I even had a trial patch at one point (which turned out not to > work terribly well, but maybe somebody will have a better idea someday). I'm pretty doubtful that there's going to be a general solution to this problem - I think it's going to require gradual refactoring of problem spots. > In the meantime, the proposal at hand seems like a bit of a stop-gap, > which is why I'd prefer to see something with a very minimal code > footprint. Detoast at assignment would likely need only a few lines > of code added in a single place. OK. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: