Re: Remaining beta blockers - Mailing list pgsql-hackers

Kevin,

* Kevin Grittner (kgrittn@ymail.com) wrote:
> If there is some
> particular problem someone sees, I don't think it has been
> expressed yet, which makes it impossible to address, unless you
> count the assertion that *if* we had chosen a zero-length heap to
> represent a table with valid data we *would* have a problem?

The problem which people see is that this approach isn't a good idea and
will lead down a road to ugly hacks to make things work correctly.  It's
not a question about code correctness- it's a question about the design.
Those are two very different things but both need to be considered.

> I'm not seeing cause for panic here.

Speaking to overcharged words, I don't see any 'panic' here but rather a
strong disagreement between individuals over this design.  Actually, I'm
not even sure there is disagreement about there being a better design
for this- it sounds like everyone agrees that there is.  The question
boils down to "do we ship it with an inferior design, or hold off and do
it right the first time".

> What is a real problem or risk with using this mechanism until we
> engineer something better?  What problems with converting to a
> later major release does anyone see?

Various examples have been articulated and you've worked through
specific high-level designs for how to deal with those, which is great,
but design isn't about just those things which you can forsee and
predict, it's about ensuring flexibility is there for those things that
you don't predict.

> >> If we can't tell the difference between those two things, I
> >> don't think we should be releasing the feature.
> >
> > So, speaking of hysteria...
>
> Yeah, I know you don't get it, but as a DBA I would never have
> allowed a feature which could quietly generate false results to be
> used -- which is exactly what you have without a way to
> differentiate these cases. 

It also happens to be what you can end up having with unlogged tables
already..  We ran into exactly that issue and decided that we'd be
better off not using them (for now anyway) even for things which really
should be just transient data sets.

> If it comes down to a choice between a
> performance tweak like unlogged matviews and an issue of
> correctness of results, I will pick correctness.  Now, as I've
> already said, this tweak is significant (I expect it will make
> matviews useful in roughly twice as many cases), but it is just a
> performance tweak.

And, I think anyway, I agree w/ you (Kevin) here- we should really have
a way to tell the difference between no-data-in-query-result and
never-populated.  I'd like more options than just a big ERROR result
happening when it's never been populated, but that's a different
discussion.
Thanks,
    Stephen