Re: [CORE] RC1 blocker issues - Mailing list pgsql-hackers

On Sun, Nov 26, 2006 at 08:42:26PM -0800, Joshua D. Drake wrote:
> Tom Lane wrote:
> >"Joshua D. Drake" <jd@commandprompt.com> writes:
> >Nobody has a use-case for INSERT RETURNING, such as wanting to
> >fetch the value assigned to a serial column?
> 
> currval()? lastval()?

INSERT ... RETURNING can return a rowset, not just one particular part
of one particular row.

> > Nobody has a use for CREATE INDEX CONCURRENTLY?'
> 
> Of course they do, again need not want. CREATE INDEX CONCURRENTLY is
> a great feature but it isn't something that is whiz, bang, pow (such
> as the enormous performance increase between 7.4/8.0 and 8.1).
> 
> Our most active customers, even those with many hundreds of millions
> of rows per table, can create an index reasonably quick based on the
> hardware they run. They just schedule it to run after hours or on
> off peak.

All that needs to happen is for this to take 49 hours.  Suddenly,
there's a use case ;)

> >Nobody needs an order-of-magnitude speedup in large sorts?
> >Nobody's hit a context swap storm that might be fixed by 8.2?  I
> >could go on like this for awhile.
> 
> Don't take it personally Tom, I wasn't knocking the hard work. I was
> simply stating what I see, which is 8.1 is pretty darn good. It
> should be considered a compliment.
> 
> Of course every feature in 8.2 is appreciated, but that doesn't mean
> I have customers clamoring for them. I am just now getting most of
> our customers to move to 8.1. I still have many customers on 7.3.

That's a big problem for both you and your customers.  At some point
in the not too distant future, 7.3 will get EOLed.

> Just because something *can* do something, doesn't mean that
> customers *need* it to do so. There are certainly many
> users/customers that will benefit from 8.2 but many of my customers
> will never even install it.
> 
> If I tell a customer 8.2 is out and we get these great features and
> then I saw, but 8.3 is less than 9 months away. You can kiss the
> upgrade to 8.2 goodbye.
> 
> Especially since many of my customers are now running multi-hundred
> gigabyte databases. They need a serious reason to upgrade because it
> will be a long outage.

The performance and feature gains from 8.1 to 8.2 are fairly easy to
justify on this scale.

> >>However I know that a lot of people are trying to do *alot* of work for 
> >>8.3. I have had conversations with several individuals who want:
> >
> >>Recursive queries
> >>Multi table indexes
> >>GROUP BY/WITH
> >>Further HOT Standby Work
> >
> >>These all seem like pretty big projects to do with a short
> >>lifecycle?
> >
> >Indeed, and if not one of them appears in 8.3, I won't be very
> >surprised nor shed any tear.  The point of the short 8.3 dev cycle
> >is (a) to try to align ourselves with a better time of year for
> >beta/release cycle, and (b) to push out several big improvements
> >that are already nearly done but missed 8.2, such as bitmap
> >indexes.  Any other big projects that can be done by March will be
> >nice gravy, but they aren't going to get to dictate the schedule.
> 
> Which pushes them to 8.4 potentially, which makes things even more
> interesting because what I list above, is what *my* customers want
> and have wanted for a long time (and yes, I tell them the same thing
> everytime... any time you want to cough up some money, I will put
> developers on it :)).

Have any of them gotten close to doing this?  What approaches have you
tried?

Cheers,
D
-- 
David Fetter <david@fetter.org> http://fetter.org/
phone: +1 415 235 3778        AIM: dfetter666                             Skype: davidfetter

Remember to vote!