Kevin Grittner kgri...@ymail.com writes:
Tom Lane t...@sss.pgh.pa.us 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
Kevin Grittner kgri...@ymail.com writes:
Kevin Grittner kgri...@ymail.com 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
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
Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kgri...@ymail.com 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
Kevin Grittner kgri...@ymail.com writes:
Tom Lane t...@sss.pgh.pa.us 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
* 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
Tom Lane t...@sss.pgh.pa.us 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
Kevin Grittner kgri...@ymail.com 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
Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kgri...@ymail.com 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
Bruce Momjian br...@momjian.us 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
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 br...@momjian.us wrote:
Yes, I think the big question is how much information do we want per
relation that we don't need
Bruce Momjian br...@momjian.us 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.
On Fri, May 3, 2013 at 1:12 AM, Bruce Momjian br...@momjian.us 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 relfilenode.meta
fork that has information like this. It
On 2013-05-03 16:11:13 +0100, Greg Stark wrote:
On Fri, May 3, 2013 at 1:12 AM, Bruce Momjian br...@momjian.us 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
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 br...@momjian.us wrote:
I was more thinking of the idea of having some status on the first page
that might need to change in a
* 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),
Stephen Frost sfr...@snowman.net 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
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 some
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 the
On Fri, May 3, 2013 at 12:10:14PM -0400, Tom Lane wrote:
Stephen Frost sfr...@snowman.net 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
On 2013-05-03 12:10:14 -0400, Tom Lane wrote:
Stephen Frost sfr...@snowman.net 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
Andres Freund and...@2ndquadrant.com 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
On Fri, May 3, 2013 at 12:45:36PM -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com 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
On Fri, May 3, 2013 at 5:49 PM, Bruce Momjian br...@momjian.us 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
On Sat, May 4, 2013 at 03:04:33AM +0100, Greg Stark wrote:
On Fri, May 3, 2013 at 5:49 PM, Bruce Momjian br...@momjian.us 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
On Tue, Apr 30, 2013 at 12:02:59PM -0400, Robert Haas wrote:
On Tue, Apr 30, 2013 at 10:40 AM, Kevin Grittner kgri...@ymail.com 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
Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
Kevin Grittner kgri...@ymail.com 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
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
is
On 27 April 2013 15:59, Tom Lane t...@sss.pgh.pa.us 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
On Tue, Apr 30, 2013 at 9:23 PM, Greg Stark st...@mit.edu 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
* 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 people
Robert Haas robertmh...@gmail.com wrote:
Kevin Grittner kgri...@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
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 data
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
On Tue, Apr 30, 2013 at 7:29 AM, Kevin Grittner kgri...@ymail.com 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
Andres Freund and...@2ndquadrant.com 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
Robert Haas robertmh...@gmail.com wrote:
Kevin Grittner kgri...@ymail.com 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
On 2013-04-30 07:33:05 -0700, Kevin Grittner wrote:
Andres Freund and...@2ndquadrant.com 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
Andres Freund and...@2ndquadrant.com wrote:
On 2013-04-30 07:33:05 -0700, Kevin Grittner wrote:
Andres Freund and...@2ndquadrant.com 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
On Tue, Apr 30, 2013 at 10:40 AM, Kevin Grittner kgri...@ymail.com 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,
On 2013-04-30 08:35:32 -0700, Kevin Grittner wrote:
Andres Freund and...@2ndquadrant.com wrote:
On 2013-04-30 07:33:05 -0700, Kevin Grittner wrote:
Andres Freund and...@2ndquadrant.com wrote:
2) Since we don't have a metapage to represent scannability in 9.3
we cannot easily use one
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 with
Josh Berkus j...@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
Andres Freund and...@2ndquadrant.com 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
Andres Freund and...@2ndquadrant.com wrote:
On 2013-04-30 07:33:05 -0700, Kevin Grittner wrote:
Andres Freund and...@2ndquadrant.com 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
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 out
Josh Berkus j...@agliodbs.com 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
On Tue, Apr 30, 2013 at 10:19 PM, Kevin Grittner kgri...@ymail.com 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
Tom Lane t...@sss.pgh.pa.us 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
* 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
Stephen Frost sfr...@snowman.net 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
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.
On Mon, Apr 29, 2013 at 3:34 PM, Kevin Grittner kgri...@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
* 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 9:44 PM, Stephen Frost sfr...@snowman.net 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
On 27 April 2013 20:23, Robert Haas robertmh...@gmail.com wrote:
On Sat, Apr 27, 2013 at 10:59 AM, Tom Lane t...@sss.pgh.pa.us 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
On 27 April 2013 19:06, Tom Lane t...@sss.pgh.pa.us wrote:
Noah Misch n...@leadboat.com 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
On Sat, Apr 27, 2013 at 3:51 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sat, Apr 27, 2013 at 3:33 PM, Tom Lane t...@sss.pgh.pa.us 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
Robert Haas robertmh...@gmail.com writes:
On Sat, Apr 27, 2013 at 3:51 PM, Tom Lane t...@sss.pgh.pa.us 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
Simon Riggs si...@2ndquadrant.com 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,
On 28 April 2013 16:55, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com 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
Simon Riggs si...@2ndquadrant.com writes:
On 28 April 2013 16:55, Tom Lane t...@sss.pgh.pa.us 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
On 28 April 2013 21:06, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
On 28 April 2013 16:55, Tom Lane t...@sss.pgh.pa.us wrote:
The bottom line here is that we have substantial disagreement on how
unlogged matviews should be implemented, and there's no longer
On Sun, Apr 28, 2013 at 11:41 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sat, Apr 27, 2013 at 3:51 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I cannot say that I find that idea attractive; the biggest problem with
it being that updating such a state flag
Robert Haas robertmh...@gmail.com writes:
On Sun, Apr 28, 2013 at 11:41 AM, Tom Lane t...@sss.pgh.pa.us 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
On 29 April 2013 01:40, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sun, Apr 28, 2013 at 11:41 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Well, it's fairly clear *how* to do it: add some more processing that
occurs after we've completed crash replay. We already
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
there are at least three that seem like absolute
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,
Noah Misch n...@leadboat.com 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
On Sat, Apr 27, 2013 at 10:59 AM, Tom Lane t...@sss.pgh.pa.us 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,
Robert Haas robertmh...@gmail.com writes:
On Sat, Apr 27, 2013 at 10:59 AM, Tom Lane t...@sss.pgh.pa.us 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
On Sat, Apr 27, 2013 at 3:33 PM, Tom Lane t...@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
Robert Haas robertmh...@gmail.com writes:
On Sat, Apr 27, 2013 at 3:33 PM, Tom Lane t...@sss.pgh.pa.us 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
73 matches
Mail list logo
