* Kevin Grittner (kgri...@ymail.com) wrote:
> Since the patch we have floating around drops it, let's leave it
> that way, in the interest of saving time getting to beta. If it
> was still there, I'd probably vote to leave it for the same reason.
I'll vote for dropping it also, though for a sligh
Kevin Grittner writes:
> Tom Lane wrote:
>> It seems a bit late to be adding such a thing;
> No kidding. The same could be said for the rest of this. It was
> all talked to death months ago before I posted a patch which was
> proposed for commit. All this eleventh hour drama bothers me.
Well
Tom Lane wrote:
> Kevin Grittner writes:
>> The flip side of that is that it might be confusing to try
>> to explain why users should care which test they use before they
>> are capable of returning different results.
>
> That's a good point too, though; if they are returning the same
> thing ri
On 05/06/2013 08:17 AM, Tom Lane wrote:
Per my other mail, I think adding an AMV option at this time is
inadvisable. I could go either way on removing or keeping the
is_scannable function --- anybody else have an opinion on that point?
Which of us is going to commit this? We're running low o
Kevin Grittner writes:
> Kevin Grittner wrote:
>> That column name and the wording of some comments are the main
>> things
> Patch for that attached. I left the part where you got rid of the
> SQL function to allow users to test whether a matview is currently
> scannable, and I did not add an A
Kevin Grittner writes:
> Tom Lane wrote:
>> If you want to call the pg_class column relispopulated rather
>> than relisscannable, I have no particular objection to that
> That column name and the wording of some comments are the main
> things, although I'm also wondering whether it is bad form t
Bruce Momjian wrote:
> Things like how fresh the materialized view is certainly should
> be accessible via SQL and transactional.
Keep in mind that something like "whether the materialized view is
fresh enough to be scanned by this connection" may eventually
depend on session GUCs and the passag
Tom Lane wrote:
> Kevin Grittner writes:
>> I'm going to submit a modified version of the second patch today.
>> My biggest problems with it as it stands are the name chosen for
>> the new pg_class column, and the hard-coded assumption that this
>> relation-level flag is a good long-term indicato
Kevin Grittner writes:
> I'm going to submit a modified version of the second patch today.
> My biggest problems with it as it stands are the name chosen for
> the new pg_class column, and the hard-coded assumption that this
> relation-level flag is a good long-term indicator of whether all
> conn
Tom Lane wrote:
> In the interests of moving the discussion along, attached are
> draft patches to show what I think we should do in 9.3. The
> first patch disables the unlogged-matviews feature at the user
> level (and perhaps could be reverted someday), while the second
> one moves scannabilit
Bruce Momjian writes:
> OK, how are we for bata packaging on Monday? I don't see how we can do
> that until we decide on how to handle unlogged materialized views.
In the interests of moving the discussion along, attached are draft
patches to show what I think we should do in 9.3. The first pat
On Fri, May 3, 2013 at 10:19:42PM -0400, Bruce Momjian wrote:
> On Sat, May 4, 2013 at 03:04:33AM +0100, Greg Stark wrote:
> > On Fri, May 3, 2013 at 5:49 PM, Bruce Momjian wrote:
> > > Yes, I think the big question is how much information do we want per
> > > relation that we don't need in the
On Sat, May 4, 2013 at 03:04:33AM +0100, Greg Stark wrote:
> On Fri, May 3, 2013 at 5:49 PM, Bruce Momjian wrote:
> > Yes, I think the big question is how much information do we want per
> > relation that we don't need in the system tables.
>
> It's not that we don't need it in the system tables
On Fri, May 3, 2013 at 5:49 PM, Bruce Momjian wrote:
> Yes, I think the big question is how much information do we want per
> relation that we don't need in the system tables.
It's not that we don't need it in the system tables. It's that there's
some state that we *can't* have in the system tabl
On Fri, May 3, 2013 at 12:45:36PM -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2013-05-03 12:10:14 -0400, Tom Lane wrote:
> >> Right. The whole thing is just a kluge, which I'm convinced we'll
> >> regret sooner or later --- probably sooner.
>
> > I tentatively agree as well. The only
Andres Freund writes:
> On 2013-05-03 12:10:14 -0400, Tom Lane wrote:
>> Right. The whole thing is just a kluge, which I'm convinced we'll
>> regret sooner or later --- probably sooner.
> I tentatively agree as well. The only argument for introducing some
> additional location for such informati
On 2013-05-03 12:10:14 -0400, Tom Lane wrote:
> Stephen Frost writes:
> > I'm more concerned about moving information which really should be in
> > the system catalogs out into magic files on disk..
>
> Right. The whole thing is just a kluge, which I'm convinced we'll
> regret sooner or later --
On Fri, May 3, 2013 at 12:10:14PM -0400, Tom Lane wrote:
> Stephen Frost writes:
> > I'm more concerned about moving information which really should be in
> > the system catalogs out into magic files on disk..
>
> Right. The whole thing is just a kluge, which I'm convinced we'll
> regret sooner
On 2013-05-03 12:15:27 -0400, Alvaro Herrera wrote:
> Bruce Momjian escribió:
> > On Fri, May 3, 2013 at 05:24:54PM +0200, Andres Freund wrote:
>
> > > The problem with an extra metadata fork is that it essentially would
> > > double the files in a cluster and it would also noticeably increase th
Bruce Momjian escribió:
> On Fri, May 3, 2013 at 05:24:54PM +0200, Andres Freund wrote:
> > The problem with an extra metadata fork is that it essentially would
> > double the files in a cluster and it would also noticeably increase the
> > amount of open files we need.
> > There have been quite
Stephen Frost writes:
> I'm more concerned about moving information which really should be in
> the system catalogs out into magic files on disk..
Right. The whole thing is just a kluge, which I'm convinced we'll
regret sooner or later --- probably sooner. I would much rather drop
unlogged matv
* Andres Freund (and...@2ndquadrant.com) wrote:
> The problem with an extra metadata fork is that it essentially would
> double the files in a cluster and it would also noticeably increase the
> amount of open files we need.
Why would we need it for every relation? We have other forks (fsm, vm),
On Fri, May 3, 2013 at 05:24:54PM +0200, Andres Freund wrote:
> On 2013-05-03 16:11:13 +0100, Greg Stark wrote:
> > On Fri, May 3, 2013 at 1:12 AM, Bruce Momjian wrote:
> > > I was more thinking of the idea of having some status on the first page
> > > that might need to change in a future releas
On 2013-05-03 16:11:13 +0100, Greg Stark wrote:
> On Fri, May 3, 2013 at 1:12 AM, Bruce Momjian wrote:
> > I was more thinking of the idea of having some status on the first page
> > that might need to change in a future release.
>
> Incidentally, another option might be to have a .meta
> fork th
On Fri, May 3, 2013 at 1:12 AM, Bruce Momjian wrote:
> I was more thinking of the idea of having some status on the first page
> that might need to change in a future release.
Incidentally, another option might be to have a .meta
fork that has information like this. It doesn't fundamentally chang
On Thu, May 2, 2013 at 02:20:15PM -0700, Kevin Grittner wrote:
> > Yes, pg_upgrade is never going to write to data pages as that
> > would be slow and prevent the ability to roll back to the
> > previous cluster on error.
>
> The only person who has suggested anything which would require that
> i
Bruce Momjian wrote:
> Robert Haas wrote:
>> Kevin Grittner wrote:
> 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?
Well, it's a pg_upgrade hazard, if n
On Tue, Apr 30, 2013 at 12:02:59PM -0400, Robert Haas wrote:
> On Tue, Apr 30, 2013 at 10:40 AM, Kevin Grittner wrote:
> >>> 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
On Tue, Apr 30, 2013 at 9:23 PM, Greg Stark wrote:
> Can I ask what is the design goal of unlogged relations? Are they just
> an optimization so you can load lots of data without generating piles
> of wal log? Or are they intended to generate zero wal traffic so they
> can be populated on a standb
On 27 April 2013 15:59, Tom Lane wrote:
> 2. The checksum algorithm business. Again, we don't get to tinker with
> that anymore once we're in beta.
Checksum changes to output value and control file are now complete and
we are ready to go to beta with it.
Robert has an outstanding comment on vi
On Tue, Apr 30, 2013 at 10:19 PM, Kevin Grittner wrote:
> Clearly we would need to change how we do recovery of unlogged
> relations to both allow unlogged matviews and keep the populated
> state in pg_class. I don't think we can really make the "two
> places" technique work, where the recovery s
Josh Berkus wrote:
>> That was deemed to be incompatible with unlogged matviews, which
>> some didn't want to give up in this initial release.
>
> Huh? Unlogged tables don't go in pg_class?
Sorry if I wasn't clear. I try to do incremental development --
get one part working and then go on to t
Kevin,
> 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
Yeah, I'm just pointing o
Andres Freund wrote:
> On 2013-04-30 07:33:05 -0700, Kevin Grittner wrote:
>> Andres Freund wrote:
>>> 1) vacuum can truncate the table to an empty relation already
>>> if there is no data returned by the view's query which then
>>> leads to the wrong scannability state.
>>> So we need
Andres Freund wrote:
> Ah. Tom already fixed the problem in
> 5194024d72f33fb209e10f9ab0ada7cc67df45b7. I was working in a
> branch based on 3ccae48f44d993351e1f881761bd6c556ebd6638 and it
> failed there.
Since previous regression tests missed this bug, I've added the
test you posted, to make su
Josh Berkus 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
Robert,
> - The data can be used if the matview is fully up-to-date.
> - The data can be used if the matview is not out of date by more than
> a certain amount of time.
> - The data can be used if the matview is out of date with respect to
> one of its base tables, but not if it is out of date wit
On 2013-04-30 08:35:32 -0700, Kevin Grittner wrote:
> Andres Freund wrote:
> > On 2013-04-30 07:33:05 -0700, Kevin Grittner wrote:
> >> Andres Freund wrote:
>
> >>> 2) Since we don't have a metapage to represent scannability in 9.3
> >>> we cannot easily use one in 9.4+ without pg_upgrade emp
On Tue, Apr 30, 2013 at 10:40 AM, Kevin Grittner wrote:
>>> 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?
>>
>> Well, it's a pg_upgrade hazard, if nothing else, isn't it?
Andres Freund wrote:
> On 2013-04-30 07:33:05 -0700, Kevin Grittner wrote:
>> Andres Freund wrote:
>>> 2) Since we don't have a metapage to represent scannability in 9.3
>>> we cannot easily use one in 9.4+ without pg_upgrade emptying all
>>> matviews unless we only rely on the catalogs wh
On 2013-04-30 07:33:05 -0700, Kevin Grittner wrote:
> Andres Freund wrote:
> > 1) vacuum can truncate the table to an empty relation already if there is
> > no data returned by the view's query which then leads to the wrong
> > scannability state.
> >
> > S1: CREATE MATERIALIZED VIEW matview
Robert Haas wrote:
> Kevin Grittner wrote:
>> 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,
Andres Freund wrote:
> On 2013-04-30 04:29:26 -0700, Kevin Grittner wrote:
>> 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 REF
On Tue, Apr 30, 2013 at 7:29 AM, Kevin Grittner wrote:
> 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
Could we please stop the ad-hominem stuff from all sides? We want to
solve the issue not to make it bigger.
On 2013-04-30 04:29:26 -0700, Kevin Grittner wrote:
> Let's look at the "corner" this supposedly paints us into. If a
> later major release creates a better mechanism, current pg_dump and
>
Kevin,
* Kevin Grittner (kgri...@ymail.com) wrote:
> 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 da
Robert Haas wrote:
> Kevin Grittner 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
* Robert Haas (robertmh...@gmail.com) wrote:
> If you assume that people are going to modify files while the backend
> is running, nothing we do anywhere is safe.
I agree that it's a bad idea and that people who do such things deserve
what they get, but that doesn't mean it won't happen when peopl
On Mon, Apr 29, 2013 at 9:44 PM, Stephen Frost wrote:
> * Kevin Grittner (kgri...@ymail.com) wrote:
>> If they modified the heap files that way while the server was
>> running, the results would be somewhat unpredictable. If they did
>> it while the server was stopped, starting the server and att
* Kevin Grittner (kgri...@ymail.com) wrote:
> If they modified the heap files that way while the server was
> running, the results would be somewhat unpredictable. If they did
> it while the server was stopped, starting the server and attempting
> to access the matview would generate:
Right, the
On Mon, Apr 29, 2013 at 3:34 PM, Kevin Grittner 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 fo
>> what happens when an admin figures out that they can 'hack' the
>> system to do what they want by truncating that file?
That can't possibly be a serious objection. DBAs who mess with DB files
are on their own, and should expect unpredictable behavior.
--
Josh Berkus
PostgreSQL Experts Inc.
Stephen Frost wrote:
> what happens when an admin figures out that they can 'hack' the
> system to do what they want by truncating that file?
If they modified the heap files that way while the server was
running, the results would be somewhat unpredictable. If they did
it while the server was s
* Kevin Grittner (kgri...@ymail.com) wrote:
> Many people weighed in on the need to differentiate between an
> empty matview and one which has not been populated. Many have also
> weighed in on the benefits of unlogged matviews.
Sure, I think I did that- we should be able to distinguish between t
Tom Lane wrote:
> [ shrug... ] You and Kevin essentially repeated your claims that
> the current implementation is OK; nobody else weighed in.
Many people weighed in on the need to differentiate between an
empty matview and one which has not been populated. Many have also
weighed in on the ben
On 29 April 2013 01:40, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Apr 28, 2013 at 11:41 AM, Tom Lane wrote:
>>> Well, it's fairly clear *how* to do it: add some more processing that
>>> occurs after we've completed crash replay. We already have some of
>>> that, eg completion of partial
Robert Haas writes:
> On Sun, Apr 28, 2013 at 11:41 AM, Tom Lane wrote:
>> Well, it's fairly clear *how* to do it: add some more processing that
>> occurs after we've completed crash replay. We already have some of
>> that, eg completion of partial splits in btrees, so it's not that much
>> of a
On Sun, Apr 28, 2013 at 11:41 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Sat, Apr 27, 2013 at 3:51 PM, Tom Lane wrote:
>>> I cannot say that I find that idea attractive; the biggest problem with
>>> it being that updating such a state flag will be nontransactional,
>>> unless we go to a lot
On 28 April 2013 21:06, Tom Lane wrote:
> Simon Riggs writes:
>> On 28 April 2013 16:55, Tom Lane wrote:
>>> The bottom line here is that we have substantial disagreement on how
>>> unlogged matviews should be implemented, and there's no longer enough
>>> time for coming to a resolution that wil
Simon Riggs writes:
> On 28 April 2013 16:55, Tom Lane wrote:
>> The bottom line here is that we have substantial disagreement on how
>> unlogged matviews should be implemented, and there's no longer enough
>> time for coming to a resolution that will satisfy everybody. I think
>> that means we
On 28 April 2013 16:55, Tom Lane wrote:
> Simon Riggs writes:
>> On other patches, one committer objecting to something is seen as
>> enough of a blocker to require change. That should work in every
>> direction.
>
> The bottom line here is that we have substantial disagreement on how
> unlogged
Simon Riggs writes:
> On other patches, one committer objecting to something is seen as
> enough of a blocker to require change. That should work in every
> direction.
The bottom line here is that we have substantial disagreement on how
unlogged matviews should be implemented, and there's no long
Robert Haas writes:
> On Sat, Apr 27, 2013 at 3:51 PM, Tom Lane wrote:
>> I cannot say that I find that idea attractive; the biggest problem with
>> it being that updating such a state flag will be nontransactional,
>> unless we go to a lot of effort to support rollbacks. ISTM that the
>> scanna
On Sat, Apr 27, 2013 at 3:51 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sat, Apr 27, 2013 at 3:33 PM, Tom Lane wrote:
>>> 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
On 27 April 2013 19:06, Tom Lane wrote:
> Noah Misch writes:
>> On Sat, Apr 27, 2013 at 10:59:32AM -0400, Tom Lane wrote:
>>> As far as #1 goes, I think we have little choice at this point but to
>>> remove the unlogged-matviews feature for 9.3.
>
>> This perspective is all wrong. I hate to be b
On 27 April 2013 20:23, Robert Haas wrote:
> On Sat, Apr 27, 2013 at 10:59 AM, Tom Lane wrote:
>> 2. The checksum algorithm business. Again, we don't get to tinker with
>> that anymore once we're in beta.
>
> I think it's pretty darn clear that we should change the algorithm,
> and I think we'v
Robert Haas writes:
> On Sat, Apr 27, 2013 at 3:33 PM, Tom Lane wrote:
>> 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
On Sat, Apr 27, 2013 at 3:33 PM, Tom Lane 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
Robert Haas writes:
> On Sat, Apr 27, 2013 at 10:59 AM, Tom Lane wrote:
>> Of the items on the 9.3 open-items page,
>> https://wiki.postgresql.org/wiki/PostgreSQL_9.3_Open_Items
>> there are at least three that seem like absolute drop-dead stop-ship issues:
> I completely agree. I think it's co
On Sat, Apr 27, 2013 at 10:59 AM, Tom Lane wrote:
> The schedule says we're going to wrap 9.3beta1 on Monday, but it doesn't
> feel to me like we are anywhere near ready to ship a credible beta.
> Of the items on the 9.3 open-items page,
> https://wiki.postgresql.org/wiki/PostgreSQL_9.3_Open_Items
Noah Misch writes:
> On Sat, Apr 27, 2013 at 10:59:32AM -0400, Tom Lane wrote:
>> As far as #1 goes, I think we have little choice at this point but to
>> remove the unlogged-matviews feature for 9.3.
> This perspective is all wrong. I hate to be blunt, but that thread ended with
> your technica
On Sat, Apr 27, 2013 at 10:59:32AM -0400, Tom Lane wrote:
> The schedule says we're going to wrap 9.3beta1 on Monday, but it doesn't
> feel to me like we are anywhere near ready to ship a credible beta.
> Of the items on the 9.3 open-items page,
> https://wiki.postgresql.org/wiki/PostgreSQL_9.3_Ope
72 matches
Mail list logo
