| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
| Cc: | Hans Buschmann <buschmann(at)nidsa(dot)net>, pgsql-hackers(at)postgresql(dot)org, Andres Freund <andres(at)anarazel(dot)de> |
| Subject: | Re: Assorted improvements in pg_dump |
| Date: | 2021-10-24 22:58:41 |
| Message-ID: | 3788315.1635116321@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Justin Pryzby <pryzby(at)telsasoft(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kyotaro Horiguchi | 2021-10-25 00:59:30 | Re: add retry mechanism for achieving recovery target before emitting FATA error "recovery ended before configured recovery target was reached" |
| Previous Message | Michael Paquier | 2021-10-24 22:43:11 | Re: pg_receivewal starting position |