Re: Remaining beta blockers
От | Kevin Grittner |
---|---|
Тема | Re: Remaining beta blockers |
Дата | |
Msg-id | 1367343948.28932.YahooMailNeo@web162906.mail.bf1.yahoo.com обсуждение исходный текст |
Ответ на | Re: Remaining beta blockers (Josh Berkus <josh@agliodbs.com>) |
Список | pgsql-hackers |
Josh Berkus <josh@agliodbs.com> wrote: > We discussed this around the beginning of CF4. For some reason > (which I didn't quite understand at the time), the consensus was > that creating a "matview last updated" timestamp was not > implementable for 9.3 and would need to wait for 9.4. The reason was that the start of CF4 was deemed too late in the development cycle to be trying to design what that should look like. No sooner had you suggested that one column than someone suggested two others which might also be useful, and it seemed to me that it would be hard to get it right before we had a better sense of what incremental maintenance based on the view declaration would look like. So, as I recall it, the consensus developed around the simplest possible test, which from the user perspective was hidden behind a function, should be used for this release. > Again, all of this points to additional columns, or at least > relopts, in pg_class. Why is that off the table? That was deemed to be incompatible with unlogged matviews, which some didn't want to give up in this initial release. Basically, what this patch aims at is more or less what some other databases had in their initial releases of materialized views 10 to 20 years ago. Other products have built on those foundations with each major release. I was hoping we could do the same. We are not going to reach parity on this with any other major database product in one release, or probably even two or three. I didn't dig back through all the threads to confirm these recollections, so take them with a grain of salt. The one thing I am sure of is that they are a rehash of discussions which go back to before the start of CF3. Only with more tone and urgency. -- Kevin Grittner EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: