| 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: | Whole Thread | Raw Message | 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? |