| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Joe Conway <mail(at)joeconway(dot)com> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: missing toast table for pg_policy |
| Date: | 2018-02-18 16:18:49 |
| Message-ID: | 29346.1518970729@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Joe Conway <mail(at)joeconway(dot)com> writes:
> Is there really a compelling reason to not just create toast tables for
> all system catalogs as in the attached?
What happens when you VACUUM FULL pg_class? (The associated toast table
would have to be nonempty for the test to prove much.)
I'm fairly suspicious of toasting anything that the toast mechanism itself
depends on, actually, and that would include at least pg_attribute and
pg_index as well as pg_class. Maybe we could get away with it because
there would never be any actual recursion only potential recursion ...
but it seems scary.
On the whole, I'm dubious that the risk/reward ratio is attractive here.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2018-02-18 16:48:56 | Re: different results from plpgsql functions related to last changes in master |
| Previous Message | Joe Conway | 2018-02-18 15:43:42 | Re: missing toast table for pg_policy |