Re: Efficient slicing/substring of TOAST values (for comment)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: John Gray <jgray(at)azuli(dot)co(dot)uk>
Cc: pgsql-patches(at)postgresql(dot)org
Subject: Re: Efficient slicing/substring of TOAST values (for comment)
Date: 2001-10-08 15:06:36
Message-ID: 751.1002553596@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

John Gray <jgray(at)azuli(dot)co(dot)uk> writes:
> 2. Changed e.g. textsubstr and byteasubstr to use this method.
> textsubstr is complicated by the multibyte support -the fast method is
> only applicable in a non-multibyte environment.

More accurately, it's only applicable in single-byte character sets,
which is a useful fraction of the MULTIBYTE world too. Keep in mind
that MULTIBYTE is likely to default to ON in the near future, so there's
little point in such an exercise if you are going to ifdef it out.
I believe there's a routine somewhere that will tell you whether the
current database encoding is single-byte or multi-byte.

> 3. Added any facility to force a column to have attstorage 'e'. At
> present it appears to be defaulted from typstorage, but I couldn't see
> any problem with changing it after table creation. Would a keyword to
> CREATE TABLE to override the default attstorage be useful?

I've been envisioning adding an ALTER TABLE variant to do this, rather
than mucking up CREATE TABLE --- compare the handling of attstattarget.

> Of course, this may just all be useless feature bloat

No, this has been a to-do item for awhile. I think it's a tad too late
to think in terms of squeezing it into 7.2, but keep working on it for
7.3.

Have you got any ideas about the update side of the problem?

regards, tom lane

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message steve 2001-10-08 16:34:51 pg_dump oid problems
Previous Message John Gray 2001-10-08 13:52:39 Efficient slicing/substring of TOAST values (for comment)