Re: Remaining beta blockers

From: Kevin Grittner <kgrittn(at)ymail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Noah Misch <noah(at)leadboat(dot)com>, "pgsql-hackers(at)postgreSQL(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Remaining beta blockers
Date: 2013-04-30 11:29:26
Message-ID: 1367321366.39391.YahooMailNeo@web162901.mail.bf1.yahoo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> Kevin Grittner <kgrittn(at)ymail(dot)com> wrote:

>> The hysteria and FUD about using the currently-supported technique
>> for unlogged tables to implement unlogged matviews are very
>> discouraging.  And the notion that we would release a matview
>> feature which allowed false results (in the form of treating a
>> never-populated matview as a legal empty matview) is truly scary to
>> me.
>
> I think that labeling other people's concerns as hysteria and FUD is
> not something which will advance the debate.

The point of that language is that "charged" language which has
nothing to do with reality is already being thrown around; by all
means let's get back to constructive discussion.  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?

Let's look at the "corner" this supposedly paints us into.  If a
later major release creates a better mechanism, current pg_dump and
load will already use it, based on the way matviews are created
empty and REFRESHed by pg_dump.  Worst case, we need to modify the
behavior of pg_dump running with the switch used by pg_upgrade to
use a new ALTER MATERIALIZED VIEW SET (populated); (or whatever
syntax is chosen) -- a command we would probably want at that point
anyway.  I'm not seeing cause for panic here.

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?

>> 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.  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.

--
Kevin Grittner
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joel Jacobson 2013-04-30 11:34:44 Re: The missing pg_get_*def functions
Previous Message Ants Aasma 2013-04-30 11:23:35 Re: Substituting Checksum Algorithm (was: Enabling Checksums)