Re: Buglet in "Sort Method" explain output in degenerate case

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "PostgreSQL-development Hackers" <pgsql-patches(at)postgresql(dot)org>
Subject: Re: Buglet in "Sort Method" explain output in degenerate case
Date: 2007-09-01 20:43:42
Message-ID: 878x7qjev5.fsf@oxford.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches


"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Setting it at conclusion is correct, I think, since if we ever changed
> the code to abandon TSS_BOUNDED state in the face of unexpected memory
> growth, it would be wrong to have set it in make_bounded_sort.

Actually that would be pretty easy to do and strikes me as worth doing. It
isn't hard to contrive an example that over-runs work_mem though I'm not sure
how easy it would be to actually run out of RAM.

One thing though, we would have to let up on switching to bounded sort if we
run out of memory accumulating tuples. We wouldn't want to switch to bounded
sort and then spill to disk right afterward. Here I just added 10% assuming
usually the remaining tuples won't be 10% larger than the first batch.
Introducing floating point math in here kind of bothers me though.

Attachment Content-Type Size
bounded-sort-failover.patch text/x-diff 2.1 KB

In response to

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2007-09-02 02:26:06 WIP patch for per-function GUC settings
Previous Message Tom Lane 2007-09-01 18:50:05 Re: Buglet in "Sort Method" explain output in degenerate case