RE: [HACKERS] MAX Query length

Поиск
Список
Период
Сортировка
От Ansley, Michael
Тема RE: [HACKERS] MAX Query length
Дата
Msg-id 1BF7C7482189D211B03F00805F8527F70ED03C@S-NATH-EXCH2
обсуждение исходный текст
Ответы Re: [HACKERS] MAX Query length  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: wieck@debis.com (Jan Wieck)
Дата:
Сообщение: Re: [HACKERS] MAX Query length
Следующее
От: Louis Bertrand
Дата:
Сообщение: Re: [HACKERS] Updated TODO list