| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Claudio Freire <klaussfreire(at)gmail(dot)com>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, PostgreSQL-Dev <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Vacuum: allow usage of more than 1GB of work mem |
| Date: | 2016-09-06 18:11:49 |
| Message-ID: | 7684.1473185509@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> Is there a reason we can't use repalloc here?
(1) repalloc will probably copy the data.
(2) that answer doesn't excuse you from choosing a limit.
We could get around (1) by something like Robert's idea of segmented
allocation, but TBH I've seen nothing on this thread to make me think
it's necessary or would even result in any performance improvement
at all. The bigger we make that array, the worse index-cleaning
is going to perform, and complicating the data structure will add
another hit on top of that.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Corey Huinker | 2016-09-06 18:12:59 | Re: Let file_fdw access COPY FROM PROGRAM |
| Previous Message | Robert Haas | 2016-09-06 18:09:59 | Re: Vacuum: allow usage of more than 1GB of work mem |