Re: [HACKERS] generic LONG VARLENA

Tom Lane wrote:

> wieck(at)debis(dot)com (Jan Wieck) writes:
>
> Per-type control doesn't strike me as interesting or useful. If there
> needs to be a control at all, which I doubt, per-table would be the

Isn't intended to be a runtime configuration. Just a
temporary feature to restrict the attributes that can be
moved off to those types, where WE know that the adt
functions are prepared for them. If we finally have all
builtin types finished for LONG handling, it will be removed,
making user defined types LONGable too.

> > I don't think it is a good idea to create the expansion
> > relation all the time. Some keyword in CREATE TABLE, and/or
> > another ALTER TABLE should do it instead, so the DB admin can
> > activate the LONG feature on a per table base as needed.
>
> I don't believe it. See above: people will complain that it's a bug
> that the system doesn't handle their long data values. Saying "oh, you
> have to turn it on" will not appease them. My objection is really the
> same as for the specialized LONG datatype: I do *not* want people to
> have to put nonstandard junk into their database schema declarations
> in order to activate this feature. I think it should Just Work and
> stay out of users' faces.
>
> Creating the expansion relation isn't that big a deal, but if you
> don't want to do it always, why not do it on first use?

So you want to do a heap_create_with_catalog() plus
index_create()'s from inside the heap_insert() or
heap_update(). Cannot be done from anywhere else, because
that's the point where we recognize the need. I don't think
that's a good idea. What would happen if

Xact 1 needs expansion relation and creates it.
Xact 2 needs expansion relation too and uses that one
Xact 1 aborts
Xact 2 commits

Better to put out an explanative error message if tuple too
big and no expansion relation exists, than dealing with
trouble when autocreating it. If it later turns out that it
can safely work as an automated process, we can do it in a
subsequent release.

> > Also I would like to say that system relations cannot have
> > expansion relations. At least not until we have enough
> > experience with this stuff.
>
> I'd really, really, really like to have this work for rules, though.
> Why shouldn't we allow it for system relations? Most of the critical
> ones have fixed-width tuples anyway, so it won't matter for them.

Me too, and for function source text again.

But this time, you include the syscache into the entire
approach too.

> BTW, it strikes me we should drop the "lztext" special datatype, and
> instead have compression automatically applied to any varlena that
> we are contemplating putting out-of-line. (If we're really lucky,
> that saves us having to put the value out-of-line!)

Nice idea, and should be technically easy since the
compressor itself is separated from the lztext type. OTOH the
user then will have no choice to prevent compression tries
for performance reasons.

So this feature again is something that IMHO should go into a
configurable option.

> > Is that now what we initially want to give a try? If so, I
> > would like to start soon to get the generic part ready ASAP.
> > Others could then join in and contribute by adding LONG
> > support for all the VARLENA data types we have.
>
> Yes, if we don't do it inside fastgetattr then there's a lot of code
> that will have to change.

That's why I'd like a small number of types involved at
first.

And there we're back on the "release what we have now"
discussion again. Some like to get new functionality out in
a couple of smaller steps, than doing the big all-in-one
roll. Some not. Seems we can never get a consensus on that
:-(

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) #