Re: Size of pg_rewrite (Was: Report checkpoint progress with pg_stat_progress_checkpoint)

2022-04-08 Thread Andres Freund
ppend >operator and cast nodes. My inclination is that the mapping functions should be c functions. There's really no point in doing it in SQL and it comes at a noticable price. And, if done in C, we can fix mistakes in minor releases, which we can't in SQL. ># Future work; nodeToString /

Re: Size of pg_rewrite

2022-04-08 Thread Matthias van de Meent
On Fri, 8 Apr 2022 at 17:20, Dagfinn Ilmari Mannsåker wrote: > > Matthias van de Meent writes: > > > But, as text literal concatenations don't seem to get constant folded > > before storing them in the rules table, this rewrite of the views > > would result in long lines in the system_views.sql

Re: Size of pg_rewrite

2022-04-08 Thread Dagfinn Ilmari Mannsåker
Matthias van de Meent writes: > But, as text literal concatenations don't seem to get constant folded > before storing them in the rules table, this rewrite of the views > would result in long lines in the system_views.sql file, or we'd have > to deal with the additional overhead of the append

Size of pg_rewrite (Was: Report checkpoint progress with pg_stat_progress_checkpoint)

2022-04-08 Thread Matthias van de Meent
Node, all rewrite rules Additionally, we might want to consider other changes like default (or empty value) elision in nodeToString, if that is considered a reasonable option and if we really want to reduce the size of the pg_rewrite table. I think a lot of space can be recovered from that: A manua