Обсуждение: pg_largeobject and toast

hi,

what's a supposed way for a user to create a toast table?
the comment in include/storage/large_object.h
("unless the user creates a toast-table for pg_largeobject...")
made me think there's a way, but i couldn't find one.

currently, the pg_largeobject table is created without a toast table
while it has a column with the EXTENDED storage parameter and
needs_toast_table() would return true for it.
so, a unrelated modification like the following will create
a toast table for it.  is it considered a bug?

    alter table pg_largeobject alter column data set statistics -1;

(it's convenient for me as it doesn't require allow_system_table_mods=on,
but...)

YAMAMOTO Takashi

yamt@mwd.biglobe.ne.jp (YAMAMOTO Takashi) writes:
> what's a supposed way for a user to create a toast table?
> the comment in include/storage/large_object.h
> ("unless the user creates a toast-table for pg_largeobject...")
> made me think there's a way, but i couldn't find one.

At one time there was an actual command ALTER TABLE foo CREATE TOAST TABLE
(or something close to that, don't recall the exact spelling) that
in principle could have been invoked on pg_largeobject.  That's not
there anymore, but as you say it's still possible for pg_largeobject
to acquire a toast table if you're willing to perform random ALTERs
on it.  It's not recommended of course; given the usage of the table,
it could only be a performance loss.

            regards, tom lane

hi,

> yamt@mwd.biglobe.ne.jp (YAMAMOTO Takashi) writes:
>> what's a supposed way for a user to create a toast table?
>> the comment in include/storage/large_object.h
>> ("unless the user creates a toast-table for pg_largeobject...")
>> made me think there's a way, but i couldn't find one.
>
> At one time there was an actual command ALTER TABLE foo CREATE TOAST TABLE
> (or something close to that, don't recall the exact spelling) that
> in principle could have been invoked on pg_largeobject.  That's not
> there anymore, but as you say it's still possible for pg_largeobject
> to acquire a toast table if you're willing to perform random ALTERs
> on it.  It's not recommended of course; given the usage of the table,
> it could only be a performance loss.

thanks for explanation.

is it too complicated to make the database bootstrap process perform
SET STORAGE equivalent so that random ALTERs on the table doesn't
trigger toast creation?

YAMAMOTO Takashi

>
>             regards, tom lane

yamt@mwd.biglobe.ne.jp (YAMAMOTO Takashi) writes:
>> At one time there was an actual command ALTER TABLE foo CREATE TOAST TABLE
>> (or something close to that, don't recall the exact spelling) that
>> in principle could have been invoked on pg_largeobject.  That's not
>> there anymore, but as you say it's still possible for pg_largeobject
>> to acquire a toast table if you're willing to perform random ALTERs
>> on it.

> is it too complicated to make the database bootstrap process perform
> SET STORAGE equivalent so that random ALTERs on the table doesn't
> trigger toast creation?

I guess the answer to that is what the heck are you doing doing random
ALTERs on a system catalog?  It's not clear to me that we should be
putting in kluges to cause such things to have nonstandard effects.
Superusers are assumed to know what they're doing.

            regards, tom lane

hi,

> yamt@mwd.biglobe.ne.jp (YAMAMOTO Takashi) writes:
>>> At one time there was an actual command ALTER TABLE foo CREATE TOAST TABLE
>>> (or something close to that, don't recall the exact spelling) that
>>> in principle could have been invoked on pg_largeobject.  That's not
>>> there anymore, but as you say it's still possible for pg_largeobject
>>> to acquire a toast table if you're willing to perform random ALTERs
>>> on it.
>
>> is it too complicated to make the database bootstrap process perform
>> SET STORAGE equivalent so that random ALTERs on the table doesn't
>> trigger toast creation?
>
> I guess the answer to that is what the heck are you doing doing random
> ALTERs on a system catalog?  It's not clear to me that we should be
> putting in kluges to cause such things to have nonstandard effects.
> Superusers are assumed to know what they're doing.

well, a novice user (me) got surprised by the behaviour when learning
postgresql and asked a possibly stupid question.  that's all.
i have no particular reason to do random ALTERs on a system catalog except
curiosity.

IMO it's better if system catalogs behave similar to ordinary tables
where possible.  but surely it depends on how much kludge is necessary
for it.

YAMAMOTO Takashi

>
>             regards, tom lane