| From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
|---|---|
| To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | <pgsql-hackers(at)postgreSQL(dot)org> |
| Subject: | Re: Interesting misbehavior of repalloc() |
| Date: | 2007-08-11 21:07:36 |
| Message-ID: | 87bqdd231j.fsf@oxford.xeocode.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Perhaps we should just remove lines 934-982 of aset.c, and always handle
> small-chunk reallocs with the "brute force" case. Can anyone see a way
> to salvage something from the "realloc-in-place" idea?
>
> One thought that comes to mind is to try to make AllocSetFree recognize
> when it's pfree'ing the last chunk in a memory block, and to handle that
> by decrementing the freeptr instead of putting the chunk into any
> freelist.
We could also only do the realloc-in-place only if there isn't a 4k chunk in
the 4k freelist. I'm imagining that usually there wouldn't be.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | April Lorenzen | 2007-08-11 21:32:12 | proper way to fix information_schema.key_column_usage view |
| Previous Message | Tom Lane | 2007-08-11 20:29:27 | Re: Interesting misbehavior of repalloc() |