On Tue, Dec 31, 2019 at 10:25:26AM +1030, Andrew Dunstan wrote:
>On Tue, Dec 31, 2019 at 10:16 AM Andrew Dunstan
><andrew.dunstan@2ndquadrant.com> wrote:
>>
>> On Tue, Dec 31, 2019 at 9:38 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>
>> >
>> > This doesn't seem like a reason not to allow a higher limit, like a
>> > megabyte or so, but I'm not sure that pushing it to the moon would be
>> > wise.
>> >
>>
>>
>> Just to get a mental handle on the size of queries we might be
>> allowing before truncation, I did some very rough arithmetic on what
>> well known texts might fit in a megabyte. By my calculations you could
>> fit about four Animal Farms or one Madame Bovary in about a megabyte.
>> So I think that seems like more than enough :-). (My mind kinda
>> explores at the thought of debugging a query as long as Animal Farm.)
>>
>
>
>Turns out my arithmetic was a bit off. Animal Farm is 90 kb, Madame
>Bovary 678 Kb.
>
Not sure, but the Animal Farm text I found is about ~450kB (~120 pages,
with ~3kB per page) ...
Anyway, the longest queries I personally saw in production were a couple
of kB long (~32kB IIRC, it's been a couple years ago). The queries were
generated by the application (not quite a traditional ORM, but something
like it), with long identifiers (e.g. table names) pretty long due to
including a hash (so being 63 characters most of the time). Plus the
columns were always fully qualified, with multiple joins etc.
Not sure what a good limit would be. Obviously, if we pick value X, the
next day someone will come asking for X+1 ... ;-)
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services