RE: [HACKERS] MAX Query length

From: "Ansley, Michael" <Michael(dot)Ansley(at)intec(dot)co(dot)za>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: RE: [HACKERS] MAX Query length
Date: 1999-07-15 08:56:42
Message-ID: 1BF7C7482189D211B03F00805F8527F70ED03C@S-NATH-EXCH2
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)debis(dot)com
>> (Jan Wieck) #
>>
>>
>>

Browse pgsql-hackers by date

  From Date Subject
Next Message Uncle George 1999-07-15 10:44:12 Re: [PORTS] RedHat6.0 & Alpha
Previous Message Jan Wieck 1999-07-15 08:36:16 Re: [HACKERS] MAX Query length