Re: Assorted improvements in pg_dump - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Assorted improvements in pg_dump
Date
Msg-id 3788315.1635116321@sss.pgh.pa.us
Whole thread Raw
In response to Re: Assorted improvements in pg_dump  (Justin Pryzby <pryzby@telsasoft.com>)
List pgsql-hackers
Justin Pryzby <pryzby@telsasoft.com> writes:
> On Sun, Oct 24, 2021 at 05:10:55PM -0400, Tom Lane wrote:
>> +               if (tbloids->len > 1)

> I think this should say
> +               if (tbloids->len > 0)

No, >1 is the correct test, because it's checking the string length
and we started by stuffing a '{' into the string.  Maybe needs a
comment.

> BTW, the ACL patch makes the overhead 6x lower (6.9sec vs 1.2sec) for pg_dump -t
> of a single, small table.  Thanks for that.

Yeah --- I haven't done any formal measurements of the case where you're
selecting a small number of tables, but I did note that it decreased a
good deal compared to HEAD.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: pg_receivewal starting position
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: add retry mechanism for achieving recovery target before emitting FATA error "recovery ended before configured recovery target was reached"