Re: Remaining beta blockers

Поиск
Список
Период
Сортировка
От Kevin Grittner
Тема Re: Remaining beta blockers
Дата
Msg-id 1367321366.39391.YahooMailNeo@web162901.mail.bf1.yahoo.com
обсуждение исходный текст
Ответ на Re: Remaining beta blockers  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Remaining beta blockers  (Stephen Frost <sfrost@snowman.net>)
Re: Remaining beta blockers  (Andres Freund <andres@2ndquadrant.com>)
Re: Remaining beta blockers  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> wrote:
> Kevin Grittner <kgrittn@ymail.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Ants Aasma
Дата:
Сообщение: Re: Substituting Checksum Algorithm (was: Enabling Checksums)
Следующее
От: Joel Jacobson
Дата:
Сообщение: Re: The missing pg_get_*def functions