Bruce Momjian wrote:
> > While this is great and all, what will happen when long tuples finally get
> > done? Will you remove this, or keep it, or just make LONG and TEXT
> > equivalent? I fear that elaborate structures will be put in place here
> > that might perhaps only be of use for one release cycle.
>
> I think the idea is that Jan's idea is better than chaining tuples.
Just as Tom already pointed out, it cannot completely replace
tuple chaining because of the atomicy assumption of single
fsync(2) operation in current code. Due to this, we cannot
get around the cases LONG will leave open by simply raising
BLKSIZE, we instead need to tackle that anyways.
But I believe LONG would still be something worth the efford.
It will lower the pressure on chained tuples, giving us more
time to build a really good solution, and I think LONG can
survive tuple chaining and live in coexistance with it. As
said in my last mail, I still believe that not touching LONG
values at UPDATE can avoid storing the same huge value again.
And that's a benefit, tuple chaining will never give us.
Remember: If your only tool is a hammer, anything MUST look
like a nail. So why not provide a richer set of tools?
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
