Re: max_allowed_packet equivalent in Postgres?
От | Sam Mason |
---|---|
Тема | Re: max_allowed_packet equivalent in Postgres? |
Дата | |
Msg-id | 20090813233330.GK5407@samason.me.uk обсуждение исходный текст |
Ответ на | Re: max_allowed_packet equivalent in Postgres? (Greg Stark <gsstark@mit.edu>) |
Ответы |
Re: max_allowed_packet equivalent in Postgres?
|
Список | pgsql-general |
On Fri, Aug 14, 2009 at 12:03:37AM +0100, Greg Stark wrote: > On Thu, Aug 13, 2009 at 11:20 PM, Sam Mason<sam@samason.me.uk> wrote: > > Is it worth having a note about having enough memory floating around > > for those limits to actually be hit in practice? There would be no > > way of creating a row 1.6TB in size in one go, it would be ~800 UPDATE > > statements to get it up to that size as far as I can see. > > That wouldn't work actually. If you did something like "UPDATE tab set > a = a || a" the first thing Postgres does when it executes the > concatenation operator is retrieve the original a and decompress it > (twice in this case). Then it constructs the result entirely in memory > before toasting. At the very least one copy of "a" and one copy of the > compressed "a" have to fit in memory. Yup, that would indeed break---I was thinking of a single update per column. The ~800 comes from the fact that I think you may just about be able to squeeze two 1GB literals into memory at a time and hence update two of your 1600 columns with each update. > To work with objects which don't fit comfortably in memory you really > have to use the lo interface. Toast lets you get away with it only for > special cases like substr() or length() but not in general. Yup, the lo interface is of course much better for this sort of thing. -- Sam http://samason.me.uk/
В списке pgsql-general по дате отправления: