Re: Remaining beta blockers
От | Robert Haas |
---|---|
Тема | Re: Remaining beta blockers |
Дата | |
Msg-id | CA+TgmoY6Pewtx7f1Mqtm6EzdCvVcpg3kx4BP8utZyGMUh6c2Fw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Remaining beta blockers (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Remaining beta blockers
|
Список | pgsql-hackers |
On Sat, Apr 27, 2013 at 3:33 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> 1. The matviews mess. Changing that will force initdb, more than >>> likely, so we need it resolved before beta1. > >> I would like to rip out the whole notion of whether a materialized >> view is scannable and am happy to do that on Monday if you're willing >> to sit still for it. > > That would actually be my druthers too; while I see that we're going to > want such a concept eventually, I'm not convinced that the current > feature is a reasonable (and upward-compatible) subset of what we'll > want later. However, when I proposed doing that earlier, Kevin > complained pretty strenuously. I'm willing to yield on the point, > as long as the implementation doesn't make use of storage-file size > to represent scannability. > >> I think that's better than failing to support >> unlogged relations, and I'm confident that the decision to put the >> scannability flag in pg_class rather than the backing file is dead >> wrong. At the same time, I *also* agree that using the file size as a >> flag is untenable. > > Um, wait, it's *not* in pg_class now, and what I was about to do was > go put it there. Is there a typo in the above para, or are you saying > you don't like either approach? If the latter, what concept have you > got for an eventual implementation? If we're going to have it at all, I'd like to make it a flag in the page header on page 0, or maybe have a dedicated metapage that stores that detail, and perhaps other things. But really, I'd rather not have it at all. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: