Re: [HACKERS] [ patch ] pg_dump: new --custom-fetch-table and--custom-fetch-value parameters

>> I have solve it adding two new parameters, --custom-fetch-table and
>> --custom-fetch-value, to fetch less records for the specified table(s).

> Giving the user the ability to change the fetch size sounds interesting,
> though do we really need to specify it per table? What about just a
> --fetch-size=X option?

...

> I don't particularly like the use of 'custom' in the name of the option,
> seems like it's just a noise word and not really necessary.

I have used "custom" parameters because I want to decrease the fetch size only on the tables with big bloab fields. If
weremove the "custom-fetch-table" parameter and we provide only the "fetch-size" parameter all the tables will use the
newfetch size and the execution time will be slower (according to my few tests). But just "fetch-size" will be faster
touse and maybe more clear. 
Well, how to go on? I add it to the commitfest and somebody will decide and fix it?
Please, let me know
Thank you
Andrea
 

Sent: Wednesday, December 21, 2016 at 6:44 PM
From: "Stephen Frost" <sfrost@snowman.net>
To: "Andrea Urbani" <matfanjol@mail.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] [ patch ] pg_dump: new --custom-fetch-table and --custom-fetch-value parameters
Andrea,

* Andrea Urbani (matfanjol@mail.com) wrote:
> I had a problem with a Postgresql 9.3.5 on 32 bit linux, old 2.6.26
> kernel:

Ok, though, to be clear, this is a feature request, so we wouldn't
back-patch adding this to pg_dump.

> I have solve it adding two new parameters, --custom-fetch-table and
> --custom-fetch-value, to fetch less records for the specified table(s).

Giving the user the ability to change the fetch size sounds interesting,
though do we really need to specify it per table? What about just a
--fetch-size=X option?

> This does not completely solve the problem, but it helps you to get more
> chance to be able to dump your database.

That is certainly a worthwhile goal.

>     pg_dump --dbname=healthorganizer --username=hor --column-inserts
> --custom-fetch-table='"tDocumentsFiles"' --custom-fetch-value=25

I don't particularly like the use of 'custom' in the name of the option,
seems like it's just a noise word and not really necessary.

> I haven't tested the documentation: too many problems while building it
> (also the original version, without my changes; probably I have bogus
> tools... and too less time to check/try...).
> Attached the patches for the master and REL9_6_STABLE.

I agree the documentation can be a bit of a pain, but there's a lot of
issues with the patch itself when it comes to the project style. The
indentation doesn't look like it's all correct, and multi-line comments
should be of the form:

/*
* text here
*/

Lastly, it'd be good to have this patch added to
https://commitfest.postgresql.org to have it formally reviewed in the
commitfest cycle coming up in January.

Thanks!

Stephen