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