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