Andres Freund <and...@2ndquadrant.com> writes: > On 2014-01-06 12:40:25 -0500, Robert Haas wrote: >> Is "forcibly detoast everything" a complete no-go? I realize there >> are performance concerns with that approach, but I'm not sure how >> realistic a worry it actually is.
> The scenario I am primarily worried about is turning a record assignment > which previously took up to BLOCK_SIZE + slop amount of memory into > something taking up to a gigabyte. That's a pretty damn hefty > change. > And there's no good way of preventing it short of using a variable for > each actually desired column which imnsho isn't really a solution. Dunno ... if you have a table that contains a gigabyte-width column, should you be all that surprised if "SELECT * INTO r FROM table" results in "r" occupying about a gigabyte? And I can't count the number of times I've heard people deprecate using "SELECT *" at all in production code, so I don't agree with the claim that listing the columns you want is an unacceptable solution. I don't doubt that there are some folks for whom this would be a noticeable space-consumption hit compared to current behavior, but I have a hard time working up a lot of sympathy for them. I'm more concerned about the possible performance hit from detoasting more-reasonably-sized columns (say in the tens-of-KB range) when they might not get used. But we really need to benchmark that rather than just guess about whether it's a problem. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers