Re: Make deparsing of column defaults faster

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Justin Pryzby <pryzby(at)telsasoft(dot)com>
Subject: Re: Make deparsing of column defaults faster
Date: 2018-07-30 11:03:50
Message-ID: 7ac4027d-b4f1-3232-95e7-b4153222cb8c@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 07/07/2018 20:07, Jeff Janes wrote:
> One case that your patch doesn't improve (neither does my posted one) is
> check constraints.  To fix that, pg_get_constraintdef_worker would also
> need to grow a cache as well.  I don't know how often people put check
> constraints on most of the columns of a table.  Some people like their
> NOT NULL constraints to be named, not implicit.
>
> But from the bigger picture of making pg_upgrade faster, a major issue
> is that while pg_dump -s gets faster for the column default case, the
> restore of that dump is still slow (again, my posted patch also doesn't
> fix that).  In that case it is deparse_context_for called from
> StoreAttrDefault which is slow.

Any thoughts on how to proceed here? It seems there is more work to do
to cover all the issues with dumping and restoring tables with many
columns. Since the original report was in the context of pg_upgrade, we
should surely address at least the pg_restore slowness.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Janes 2018-07-30 11:51:23 Re: Make deparsing of column defaults faster
Previous Message Tomas Vondra 2018-07-30 10:42:51 Re: [PATCH] Improve geometric types