Skip site navigation (1) Skip section navigation (2)

Re: memory context for tuplesort return values

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: memory context for tuplesort return values
Date: 2006-02-24 16:51:47
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> On Thu, 2006-02-23 at 16:10 -0500, Tom Lane wrote:
>> I don't want to give up the idea of keeping sort-local data in a
>> private
>> context --- it just seems cleaner, as well as faster, than letting it
>> be
>> mixed into the caller's stuff.  I can see two alternatives:

> Would that be a single context for all sort operations, or a separate
> context for each sort within a plan?

A private context for each sort operation.  Otherwise you lose the
point, which is to be able to use MemoryContextDelete to clean up
in tuplesort_end.

> There is some evidence that high sort memory is not that useful during
> the final merge phase. Would it be possible to have multiple contexts
> within each sort e.g. Run Forming context and Final Merge context? That
> would then allow us to more easily free the Run Forming context before
> moving into the final context with a potentially different size.

Possible, but I'm not going to implement it without more evidence.
The tests I did way back when showed considerable usefulness for the
merge preload behavior, and I think that your change to allow N tapes
probably made it even more useful (because with fewer merge passes,
the tape files don't get so disorganized).  So I'm inclined to leave it

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Rod TaylorDate: 2006-02-24 16:57:46
Subject: Re: fsutil ideas
Previous:From: Jonah H. HarrisDate: 2006-02-24 16:48:42
Subject: Re: Remove ora2pg from contrib

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group