On 8/27/21, 7:27 AM, "Daniel Gustafsson" wrote:
> I took another look at this today and pushed it after verifying with a
> pgindent
> run. Thanks!
Thank you!
Nathan
> On 23 Jul 2021, at 01:39, Bossart, Nathan wrote:
> The patch looks good to me. I am marking it as ready-for-committer.
I took another look at this today and pushed it after verifying with a pgindent
run. Thanks!
--
Daniel Gustafsson https://vmware.com/
On 7/15/21, 12:48 PM, "Daniel Gustafsson" wrote:
> While unlikely to be common, very wide tables aren’t unheard of. Either way,
> I
> think it has merit to pull out the PQfnumber before the loop even if it’s a
> wash performance wise for many users, as it’s a pattern used elsewhere in
> pg_dump.
> On 15 Jul 2021, at 04:51, houzj.f...@fujitsu.com wrote:
> On July 15, 2021 5:35 AM Daniel Gustafsson wrote:
>> Out of curiosity, how many columns are "many columns"?
>
> I tried dump 10 table definitions while each table has 1000 columns
> (maybe not real world case).
While unlikely to be com
On July 15, 2021 5:35 AM Daniel Gustafsson wrote:
> > On 14 Jul 2021, at 10:54, houzj.f...@fujitsu.com wrote:
>
> > Since PQfnumber() is not a cheap function, I think we'd better invoke
> > PQfnumber() out of the loop like the attatched patch.
>
> Looks good on a quick readthrough, and I didn't
> On 14 Jul 2021, at 10:54, houzj.f...@fujitsu.com wrote:
> Since PQfnumber() is not a cheap function, I think we'd better invoke
> PQfnumber() out of the loop like the attatched patch.
Looks good on a quick readthrough, and I didn't see any other similar codepaths
in pg_dump on top of what you'v
On Wed, Jul 14, 2021 at 08:54:32AM +, houzj.f...@fujitsu.com wrote:
> Since PQfnumber() is not a cheap function, I think we'd better invoke
> PQfnumber() out of the loop like the attatched patch.
+1
Please add to the next CF
--
Justin
