Bruce Momjian <pgman@candle.pha.pa.us> writes:
> A field value over 8k is not going to be something you join on,
> restrict, or order by in most cases. It is going to be some long
> narrative or field that is just for output to the user, usually not used
> to process the query.
Not necessarily. The classic example in my mind is a text field that
the user will want to do LIKE or regexp matching searches on. When
he does so (and only when he does so), we'd have no choice but to pull
in the out-of-line value for each tuple in order to check the WHERE
clause. But we'd have to do that no matter how you slice the problem.
I think the case that is actually worth thinking about is where some
values of the column are long and some are not so long. We should avoid
a solution that imposes out-of-line storage on *every* tuple even when
the particular tuple isn't large enough to cause a problem.
I believe all of the proposals made so far have the ability to keep a
short value in-line, but the data-type-based approach has a significant
disadvantage: the decision has to be made by a data-type-specific
routine that wouldn't have information about the rest of the tuple that
the data will end up in. So it would have to err on the side of caution
and put anything more than a fairly short value out-of-line. If the
decision is made by the tuple storage routine, then it can examine the
whole tuple and make a more nearly optimal choice about what to put
out-of-line.
regards, tom lane
