Re: Path question - Mailing list pgsql-hackers

From David Fetter
Subject Re: Path question
Date
Msg-id [email protected]
Whole thread Raw
In response to Re: Path question  (Robert Haas <[email protected]>)
Responses Re: Path question
List pgsql-hackers
On Mon, Sep 20, 2010 at 10:57:00PM -0400, Robert Haas wrote:
> 2010/9/3 Hans-Jürgen Schönig <[email protected]>:
> > On Sep 2, 2010, at 1:20 AM, Robert Haas wrote:
> >> I agree. Explicit partitioning may open up some additional
> >> optimization possibilities in certain cases, but Merge Append is
> >> more general and extremely valuable in its own right.
> >
> > we have revised greg's wonderful work and ported the entire thing
> > to head.  it solves the problem of merge_append. i did some
> > testing earlier on today and it seems most important cases are
> > working nicely.
> 
> First, thanks for merging this up to HEAD.  I took a look through
> this patch tonight, and the previous reviews thereof that I was able
> to find, most notably Tom's detailed review on 2009-07-26.  I'm not
> sure whether or not it's accidental that this didn't get added to
> the CF,

It's because I missed putting it in, and oversight I've corrected.  If
we need to bounce it on to the next one, them's the breaks.

> [points elided]
> 
> 7. I think there's some basic code cleanup needed here, also: comment
> formatting, variable naming, etc.

Hans-Jürgen,

Will you be able to get to this in the next couple of days?

Cheers,
David.
-- 
David Fetter <[email protected]> http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter      XMPP: [email protected]
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate


pgsql-hackers by date:

Previous
From: Mark Kirkwood
Date:
Subject: Pg_upgrade performance
Next
From: Fujii Masao
Date:
Subject: Re: Shutting down server from a backend process, e.g. walrceiver