Re: Large expressions in indexes can't be stored (non-TOASTable)
От | Nathan Bossart |
---|---|
Тема | Re: Large expressions in indexes can't be stored (non-TOASTable) |
Дата | |
Msg-id | ZuroEfWjxd4Zj6Yq@nathan обсуждение исходный текст |
Ответ на | Re: Large expressions in indexes can't be stored (non-TOASTable) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Large expressions in indexes can't be stored (non-TOASTable)
|
Список | pgsql-hackers |
On Wed, Sep 04, 2024 at 03:20:33PM -0400, Jonathan S. Katz wrote: > On 9/4/24 3:08 PM, Tom Lane wrote: >> Nathan Bossart <nathandbossart@gmail.com> writes: >> > Thanks to commit 96cdeae, only a few catalogs remain that are missing TOAST >> > tables: pg_attribute, pg_class, pg_index, pg_largeobject, and >> > pg_largeobject_metadata. I've attached a short patch to add one for >> > pg_index, which resolves the issue cited here. This passes "check-world" >> > and didn't fail for a few ad hoc tests (e.g., VACUUM FULL on pg_index). I >> > haven't spent too much time investigating possible circularity issues, but >> > I'll note that none of the system indexes presently use the indexprs and >> > indpred columns. >> >> Yeah, the possibility of circularity seems like the main hazard, but >> I agree it's unlikely that the entries for system indexes could ever >> need out-of-line storage. There are many other things that would have >> to be improved before a system index could use indexprs or indpred. > > Agreed on the unlikeliness of that, certainly in the short-to-mid term. The > impetus driving this is dealing with a data type that can be quite large, > and it's unlikely system catalogs will be dealing with anything of that > nature, or requiring very long expressions that couldn't be encapsulated in > a different way. Any objections to committing this? I've still been unable to identify any breakage, and adding it now would give us ~1 year of testing before it'd be available in a GA release. Perhaps we should at least add something to misc_sanity.sql that verifies no system indexes are using pg_index's TOAST table. -- nathan
В списке pgsql-hackers по дате отправления: