global temporary tables
in [PgSql]
|
From: Robert Haas on 25 Apr 2010 11:35 On Sun, Apr 25, 2010 at 8:57 AM, Simon Riggs <simon(a)2ndquadrant.com> wrote: >> I don't think that quite works, because the standby might assign a >> relfilenode number for a global temp table and then the master might >> subsequently assign the same relfilenode number to a regular table. >> We might be able to make that not matter, but it's far from obvious to >> me that there are no gotchas there... > > That sounds fairly simple to solve. > > All I am saying is please include "working on the standby" as part of > your requirement. Well, I think I already basically stated my position on this, but let me try to be more clear. I'm not promising to work on any portion of this project AT ALL or to have it done at any particular time. I am specifically not promising to do the extra work required to make it work with Hot Standby, although I am also not saying that I won't. Nobody has offered to fund any portion of this work, so there are no guarantees, full stop. Even if you could successfully convince a critical mass of people on this list that the work should not be committed without adding support for temp tables in Hot Standby mode, the most likely result of that would be that I would give up and not pursue this at all, rather than that I would agree to do that in addition to solving all the problems already discussed. 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. In all honesty, I would think that you would be happy about my possibly implementing a flavor of temporary tables that would be substantially more feasible to make work with Hot Standby than the kind we have now, rather than (as you seem to be) complaining that I'm not solving the entire problem. ....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: Jim Nasby on 25 Apr 2010 10:26 On Apr 24, 2010, at 10:02 PM, Tom Lane wrote: > Robert Haas <robertmhaas(a)gmail.com> writes: >> Pushing it into the RelFileNode has some advantages in terms of being >> able to get at the information from everywhere, but one thing that >> makes me think that's probably not a good decision is that we somtimes >> WAL-log relfilenodes. And WAL-logging the value of the isTemp flag is >> a waste, because if we're WAL-logging, it's zero. > > Yeah. I think we also use RelFileNode as a hash tag in places, and > so adding a bool to it would be problematic for a couple of reasons: > possibly uninitialized pad bytes, and uselessly incorporating more bytes > into the hash calculation. Do we need to hash it that frequently? Do we insert tons of them into WAL? Worrying about those cases smells like premature optimization, but admittedly I don't have enough knowledge here... -- Jim C. Nasby, Database Architect jim(a)nasby.net 512.569.9461 (cell) http://jim.nasby.net -- 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 25 Apr 2010 15:02 Jim Nasby <decibel(a)decibel.org> writes: > On Apr 24, 2010, at 10:02 PM, Tom Lane wrote: >> Yeah. I think we also use RelFileNode as a hash tag in places, and >> so adding a bool to it would be problematic for a couple of reasons: >> possibly uninitialized pad bytes, and uselessly incorporating more bytes >> into the hash calculation. > Do we need to hash it that frequently? Every buffer access, for instance. > Do we insert tons of them into WAL? Yes; the vast majority of WAL records contain one. 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: Josh Berkus on 25 Apr 2010 17:29 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. -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.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: Andrew Dunstan on 25 Apr 2010 17:51
Josh Berkus 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. These are not mutually exclusive features. What you're asking for has value, certainly, but it's not a temp table in the standard's terms (which is a feature that also has value, I believe). cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |