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)