Thread: 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