From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Ansley, Michael" <Michael(dot)Ansley(at)intec(dot)co(dot)za>, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] MAX Query length |
Date: | 1999-07-15 14:47:44 |
Message-ID: | 6291.932050064@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I wrote:
> "Ansley, Michael" <Michael(dot)Ansley(at)intec(dot)co(dot)za> writes:
>> 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.
> As of 6.5, it's just a matter of adjusting BLCKSZ in include/config.h,
> rebuilding, and re-initdb-ing.
A further thought on this: if you increase BLCKSZ then at least some of
the fixed-size text buffers will get bigger, so it's not clear that you
will be stressing things all that hard if you take that route. Might be
easier to leave BLCKSZ alone and test with queries that are long and
complicated but don't actually require a large tuple size. Some
examples:
1. SELECT a,a,a,a,... FROM table;
2. SELECT a FROM table WHERE x = 1 OR x = 2 OR x = 3 OR ...;
3. Hugely complex CREATE TABLE commands (lots of constraints and
defaults and indexes, which don't enlarge the size of an actual
tuple of the table).
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 1999-07-15 14:58:23 | Re: [HACKERS] MAX Query length |
Previous Message | Ansley, Michael | 1999-07-15 14:11:33 | RE: [HACKERS] MAX Query length |