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
