global temporary tables
in [PgSql]
|
From: Robert Haas on 25 Apr 2010 17:54 On Sun, Apr 25, 2010 at 5:29 PM, Josh Berkus <josh(a)agliodbs.com> wrote: > Robert, > >> (1). What I *think* it is supposed to mean is that the table is a >> permanent object which is "globally" visible - that is, it's part of >> some non-temp schema like public or $user and it's column definitions >> etc. are visible to all backends - and it's not automatically removed >> on commit, backend exit, etc. - but the *contents* of the table are >> temporary and backend-local, so that each new backend initially sees >> it as empty and can then insert, update, and delete data independently >> of what any other backend does. > > While closer to the standard, the above definition is a lot less useful than > what I believe a lot of people want, which is a table which is globally > visible, but has no durability; that is, it does not get WAL-logged or > recovered on restart. Certainly this latter definition would be far more > useful to support materialized views. I think it's arguable which one is more useful, but I think a good deal of the infrastructure can be made to serve both purposes, as I further expounded upon here. http://archives.postgresql.org/pgsql-hackers/2010-04/msg01123.php ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Simon Riggs on 26 Apr 2010 15:30 On Sun, 2010-04-25 at 11:35 -0400, Robert Haas wrote: > And I don't > think you can even get that far, because I don't think too many people > here are going to say that we shouldn't add global temporary tables > unless we can also make them work with Hot Standby. The policy round here for some time has been that when we implement things we make them work fully and seamlessly. I don't see why Hot Standby would be singled out any more than any other feature, say Windows support or tablespaces should be occasionally ignored. People need to get used to the new feature set, just as we had to with HOT, subtransactions, prepared transactions, Gist etc.. That may require a thwack from various people, but the responsibility lies with the new feature implementor, not the person supporting existing code. I fully understand your wish to implement a partial feature with caveats because I have argued that many times myself. But I've come to realise that the best way is to build things so they work cleanly across the board. Other developers can plan projects in the knowledge that they can build directly on firm foundations, not fill in the cracks. In the end this comes down to a choice as developers, do we help each other by doing a full job, or do we leave unexploded bombs for each other through short-termism? Now I understand this better myself, I act differently and accept objections if people think a fuller, more complete design is what is needed. Recent demonstrations of that available, both objecting and accepting. Don't see this as an extra task, just see it as one of the many aspects that will need to be considered when developing it. If you do that it need not be additional work. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 26 Apr 2010 15:40 Simon Riggs <simon(a)2ndQuadrant.com> writes: > On Sun, 2010-04-25 at 11:35 -0400, Robert Haas wrote: >> And I don't >> think you can even get that far, because I don't think too many people >> here are going to say that we shouldn't add global temporary tables >> unless we can also make them work with Hot Standby. > The policy round here for some time has been that when we implement > things we make them work fully and seamlessly. I don't see why Hot > Standby would be singled out any more than any other feature, say > Windows support or tablespaces should be occasionally ignored. The current definition of Hot Standby is that it's a *read only* behavior. Not read mostly. What you are proposing is a rather fundamental change in the behavior of HS, and it doesn't seem to me that it should be on the head of anybody else to make it work. IOW: I agree with Robert that this is not an essential part of global temp tables. If it happens to fall out that it works like that, great, but it isn't a requirement. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Simon Riggs on 26 Apr 2010 15:50 On Mon, 2010-04-26 at 15:40 -0400, Tom Lane wrote: > Simon Riggs <simon(a)2ndQuadrant.com> writes: > > On Sun, 2010-04-25 at 11:35 -0400, Robert Haas wrote: > >> And I don't > >> think you can even get that far, because I don't think too many people > >> here are going to say that we shouldn't add global temporary tables > >> unless we can also make them work with Hot Standby. > > > The policy round here for some time has been that when we implement > > things we make them work fully and seamlessly. I don't see why Hot > > Standby would be singled out any more than any other feature, say > > Windows support or tablespaces should be occasionally ignored. > > The current definition of Hot Standby is that it's a *read only* > behavior. Not read mostly. What you are proposing is a rather > fundamental change in the behavior of HS, and it doesn't seem to me > that it should be on the head of anybody else to make it work. That's a dangerous precedent you just set. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 26 Apr 2010 16:02
On Mon, Apr 26, 2010 at 3:30 PM, Simon Riggs <simon(a)2ndquadrant.com> wrote: > On Sun, 2010-04-25 at 11:35 -0400, Robert Haas wrote: > >> And I don't >> think you can even get that far, because I don't think too many people >> here are going to say that we shouldn't add global temporary tables >> unless we can also make them work with Hot Standby. > > The policy round here for some time has been that when we implement > things we make them work fully and seamlessly. I don't see why Hot > Standby would be singled out any more than any other feature, say > Windows support or tablespaces should be occasionally ignored. > > People need to get used to the new feature set, just as we had to with > HOT, subtransactions, prepared transactions, Gist etc.. That may require > a thwack from various people, but the responsibility lies with the new > feature implementor, not the person supporting existing code. > > I fully understand your wish to implement a partial feature with caveats > because I have argued that many times myself. But I've come to realise > that the best way is to build things so they work cleanly across the > board. Other developers can plan projects in the knowledge that they can > build directly on firm foundations, not fill in the cracks. In the end > this comes down to a choice as developers, do we help each other by > doing a full job, or do we leave unexploded bombs for each other through > short-termism? Now I understand this better myself, I act differently > and accept objections if people think a fuller, more complete design is > what is needed. Recent demonstrations of that available, both objecting > and accepting. > > Don't see this as an extra task, just see it as one of the many aspects > that will need to be considered when developing it. If you do that it > need not be additional work. I think you're looking at this the wrong way. If temporary tables have to work with Hot Standby in order for it to be committable, then we should never have committed Hot Standby in the first place because our current flavor of temporary tables doesn't. Was that an oversight on your part, or a recognition that you can't solve every problem in one commit? ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |