From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Vadim Mikheev <vadim(at)krs(dot)ru> |
Cc: | Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] Planning final assault on query length limits |
Date: | 1999-10-22 15:15:41 |
Message-ID: | 20554.940605341@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Vadim Mikheev <vadim(at)krs(dot)ru> writes:
>> a fairly localized task, if I'm not greatly mistaken about it. And
> ^^^^^^^^^^^^^^
> I'm not sure. Seems that we'll have to change heap_getattr:
> if a column crosses page boundary then we'll have to re-construct
> it in memory and pfree it after using...
I was thinking more along the lines of reconstructing the whole tuple
in palloc'd memory and leaving heap_getattr as-is. Otherwise we have
problems with the system relations whose tuples are accessed as C
structs. You'd need to somehow guarantee that those tuples are never
split if you do it as above.
Of course, that just moves the palloc/pfree bookkeeping problem down
a level; it's still going to be tricky to avoid storage leaks.
We might be able to get some win from storing reassembled tuples in
TupleTableSlots, though.
>> there's plenty of time left before 7.0. So this seems like a perfect
>> project for someone who wants to learn more about the backend and has
>> some time to spend doing so.
> And we always ready to help...
Right. Questions can be answered.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Fernando Schapachnik | 1999-10-22 15:16:23 | Re: [HACKERS] Neverending query on 6.5.2 over Solaris 2.5.1 |
Previous Message | Tom Lane | 1999-10-22 15:08:01 | Re: [HACKERS] Re: [GENERAL] Postgres INSERTs much slower than MySQL? |