On 09/07/2016 09:17 AM, Peter Geoghegan wrote:
On Tue, Sep 6, 2016 at 11:09 PM, Heikki Linnakangas <hlinn...@iki.fi> wrote:
The big picture here is that you can't only USEMEM() for tapes as the
need arises for new tapes as new runs are created. You'll just run a
massive availMem deficit, that you have no way of paying back, because
you can't "liquidate assets to pay off your creditors" (e.g., release
a bit of the memtuples memory). The fact is that memtuples growth
doesn't work that way. The memtuples array never shrinks.

Hmm. But memtuples is empty, just after we have built the initial runs. Why
couldn't we shrink, i.e. free and reallocate, it?

After we've built the initial runs, we do in fact give a FREEMEM()
refund to those tapes that were not used within beginmerge(), as I
mentioned just now (with a high workMem, this is often the great
majority of many thousands of logical tapes -- that's how you get to
wasting 8% of 5GB of maintenance_work_mem).

I & peter chatted over IM on this. Let me try to summarize the problems, and my plan:

1. When we start to build the initial runs, we currently reserve memory for tape buffers, maxTapes * TAPE_BUFFER_OVERHEAD. But we only actually need the buffers for tapes that are really used. We "refund" the buffers for the unused tapes after we've built the initial runs, but we're still wasting that while building the initial runs. We didn't actually allocate it, but we could've used it for other things. Peter's solution to this was to put a cap on maxTapes.

2. My observation is that during the build-runs phase, you only actually need those tape buffers for the one tape you're currently writing to. When you switch to a different tape, you could flush and free the buffers for the old tape. So reserving maxTapes * TAPE_BUFFER_OVERHEAD is excessive, 1 * TAPE_BUFFER_OVERHEAD would be enough. logtape.c doesn't have an interface for doing that today, but it wouldn't be hard to add.

3. If we do that, we'll still have to reserve the tape buffers for all the tapes that we use during merge. So after we've built the initial runs, we'll need to reserve memory for those buffers. That might require shrinking memtuples. But that's OK: after building the initial runs, memtuples is empty, so we can shrink it.

- Heikki

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to