Re: [HACKERS] LONG

Bruce Momjian wrote:

> In fact, you may decide to just extent varchar() and text to allow use
> of long tuples. Set the varlena VARLEN field to some special value like
> -1, and when you see that, you go to pg_long to get the data. Seems
> very easy. You could get fancy and keep data in the table in most
> cases, but if the tuple length exceeds 8k, go to all the varlena fields
> and start moving data into pg_long. That way, a table with three 4k
> columns could be stored without the user even knowing pg_long is
> involved, but for shorter tuples, they are stored in the main table.

So you realized most of my explanations yourself while I
wrote the last mail. :-)

No, I don't intend to change anything on the existing data
types. Where should be the limit on which to decide to store
a datum in pg_long? Based on the datums size? On the tuple
size and attribute order, take one by one until the tuple
became small enough to fit?

Maybe we make this mechanism so general that it is
automatically applied to ALL varsize attributes? We'll end up
with on big pg_long where 90+% of the databases content will
be stored.

But as soon as an attribute stored there is used in a WHERE
or is subject to be joined, you'll see why not (as said, this
type will NOT be enabled for indexing). The operation will
probably fallback to a seq-scan on the main table and then
the attribute must be fetched from pg_long with an index scan
on every single compare etc. - no, no, no.

And it will not be one single pg_long table. Instead it will
be a separate table per table, that contains one or more LONG
attributes. IIRC, the TRUNCATE functionality was implemented
exactly to QUICKLY be able to whipe out the data from huge
relations AND get the disk space back. In the case of a
central pg_long, TRUNCATE would have to scan pg_long to mark
the tuples for deletion and vacuum must be run to really get
back the space. And a vacuum on this central pg_long would
probably take longer than the old DELETE, VACUUM of the now
truncated table itself. Again no, no, no.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck(at)debis(dot)com (Jan Wieck) #