Re: Review: Revise parallel pg_restore's scheduling heuristic

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Robert Haas" <robertmhaas(at)gmail(dot)com>
Cc: <pgsql-hackers(at)postgresql(dot)org>,"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Review: Revise parallel pg_restore's scheduling heuristic
Date: 2009-08-07 20:22:06
Message-ID: 4A7C469E0200002500029693@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I wrote:

> I remember someone else on the thread saying [...]
> it provided better structure for future enhancements.

Found the reference:

http://archives.postgresql.org/pgsql-hackers/2009-08/msg00078.php

This was the email which I thought confirmed that the changes were
worth it, even in the absence of benchmarks showing performance
improvement. I guess the counter-argument is that so far this has
been framed as a performance patch, and I've seen posts before which
say that we don't accept those without benchmarks to show an actual
performance improvement. Accepting it on the basis of evidence and
comments so far would, I suppose, put it more in the category of a
refactoring for cleaner code.

Should we leave it to the code committer to make the final call?

-Kevin

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-08-07 20:25:38 Re: Durability?
Previous Message Bruce Momjian 2009-08-07 20:16:54 Re: Re: [Pg-migrator-general] Composite types break pg_migrated tables