Grokbase › Groups › PostgreSQL › pgsql-novice › December 2010
FAQ
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

Search Discussions

  • Tom Lane at Dec 17, 2010 at 3:02 pm ⇧

    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
  • YAMAMOTO Takashi at Dec 22, 2010 at 5:33 am ⇧
    hi,
    [email protected] (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
  • Tom Lane at Dec 22, 2010 at 3:12 pm ⇧

    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
  • YAMAMOTO Takashi at Dec 22, 2010 at 11:53 pm ⇧
    hi,
    [email protected] (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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-novice @
categoriespostgresql
postedDec 17, '10 at 4:57a
activeDec 22, '10 at 11:53p
posts5
users2
websitepostgresql.org
irc#postgresql

2 users in discussion

YAMAMOTO Takashi: 3 posts Tom Lane: 2 posts

Content

People

Support

Translate

site design / logo © 2023 Grokbase