On Wed, Aug 24, 2016 at 12:39 PM, Andres Freund <and...@anarazel.de> wrote:
> > > On August 24, 2016 9:32:48 AM PDT, Tomas Vondra < > tomas.von...@2ndquadrant.com> wrote: > > > > > >On 08/24/2016 12:20 AM, Andres Freund wrote: > >> On 2016-08-23 19:18:04 -0300, Claudio Freire wrote: > >>> On Tue, Aug 23, 2016 at 7:11 PM, Tomas Vondra > >>> <tomas.von...@2ndquadrant.com> wrote: > >>>> Could someone please explain how the unlogged tables are supposed > >to fix the > >>>> catalog bloat problem, as stated in the initial patch submission? > >We'd still > >>>> need to insert/delete the catalog rows when creating/dropping the > >temporary > >>>> tables, causing the bloat. Or is there something I'm missing? > >> > >> Beats me. > >> > > > >Are you puzzled just like me, or are you puzzled why I'm puzzled? > > Like you. I don't think this addresses the problem to a significant enough > degree to care. > > Andres > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > Ok, here's a wild idea, and it probably depends on having native partitioning implemented. Propagate relpersistence, or a boolean flag on (relpersistence = 't') from pg_class into the child pg_attribute records. Partition the tables pg_class and pg_attribute first by relpersistence, and then by oid. The partitions holding data on persistent objects would basically stay as-is, but the partition wouldn't have much activity and no temp-table churn. The temporary ones, however, would fall into essentially a rotating set of partitions. Pick enough partitions such that the active transactions only cover some of the partitions. The rest can be safely truncated by vacuum. It would mitigate the bloat, existing dictionary queries would still work, but the additional lookup cost might not be worth it.
