RE: [HACKERS] MAX Query length - Mailing list pgsql-hackers

From Ansley, Michael
Subject RE: [HACKERS] MAX Query length
Date
Msg-id 1BF7C7482189D211B03F00805F8527F70ED03C@S-NATH-EXCH2
Whole thread Raw
Responses Re: [HACKERS] MAX Query length
List pgsql-hackers
Well, I'm starting on this, so hopefully in a couple of weeks the length
limit of the query buffer will fade into insignificance.
Is somebody actively working on removing the tuple-length dependence on the
block size?

At present, disk blocks are set to 8k.  Is it as easy as just adjusting the
constant to enlarge this?  Testing queries larger than 16k with only an 8k
tuple size could be challenging.


MikeA


>> > This entire chain of logic will fall to the ground anyway 
>> once we support
>> > tuples larger than a disk block, which I believe is going to happen
>> > before too much longer.  So, rather than argue about what 
>> the multiplier
>> > ought to be, I think it's more productive to just press on 
>> with making
>> > the query buffers dynamically resizable...
>> 
>>     Yes,  even  if we choose to make some other limit (like Vadim
>>     suggested around 64K), a query operating  on  them  could  be
>>     much  bigger.   I  already had some progress with a data type
>>     that uses a simple, byte oriented lz  compression  buffer  as
>>     internal representation.
>> 
>> 
>> Jan
>> 
>> --
>> 
>> #============================================================
>> ==========#
>> # It's easier to get forgiveness for being wrong than for 
>> being right. #
>> # Let's break this rule - forgive me.                        
>>           #
>> #========================================= wieck@debis.com 
>> (Jan Wieck) #
>> 
>> 
>> 


pgsql-hackers by date:

Previous
From: wieck@debis.com (Jan Wieck)
Date:
Subject: Re: [HACKERS] MAX Query length
Next
From: Louis Bertrand
Date:
Subject: Re: [HACKERS] Updated TODO list