global temporary tables
in [PgSql]
|
From: Tom Lane on 24 Apr 2010 23:02 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. 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 25 Apr 2010 03:49 On Sat, 2010-04-24 at 19:01 -0400, Robert Haas wrote: > There is one major problem, though: assigning a > scratch relfilenode to the temporary table requires generating an OID, > which we currently have no way to allow on the standby. Why not have an unlogged counter, which resets each system start, using same datatype as an oid. There's no necessity for the relfilenode to be an actual oid is there? That way we could use it on standbys also. -- 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 25 Apr 2010 06:50 On Sun, Apr 25, 2010 at 3:49 AM, Simon Riggs <simon(a)2ndquadrant.com> wrote: > On Sat, 2010-04-24 at 19:01 -0400, Robert Haas wrote: > >> There is one major problem, though: assigning a >> scratch relfilenode to the temporary table requires generating an OID, >> which we currently have no way to allow on the standby. > > Why not have an unlogged counter, which resets each system start, using > same datatype as an oid. There's no necessity for the relfilenode to be > an actual oid is there? > > That way we could use it on standbys also. 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... ....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: Robert Haas on 25 Apr 2010 08:46 On Sat, Apr 24, 2010 at 11:02 PM, Tom Lane <tgl(a)sss.pgh.pa.us> 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. Right. I was thinking about the padding issue, too. I took a crack at adding an isTemp argument to smgropen() and removing it everywhere else, but it turns out this isn't as straightforward as it ought to be because nbtsort.c, rewriteheap.c, and tablecmds.c feel entitled to violate the abstraction layer by passing isTemp = true to smgrwrite() and/or smgrextend() even when the real value is false, under the assumption that the only thing isTemp is doing in those functions is controlling fsync behavior. I think we'll have to replace the isTemp argument to those functions with a boolean whose explicit charter is to do what they're using it for. Removing the isTemp from smgrtruncate() and smgrdounlink() argument looks easy, though. WIP patch that takes it that far is attached. [davidfetter: patch description for PWN is "WIP patch to push isTemp down into the smgr layer"] ....Robert
From: Simon Riggs on 25 Apr 2010 08:57
On Sun, 2010-04-25 at 06:50 -0400, Robert Haas wrote: > On Sun, Apr 25, 2010 at 3:49 AM, Simon Riggs <simon(a)2ndquadrant.com> wrote: > > On Sat, 2010-04-24 at 19:01 -0400, Robert Haas wrote: > > > >> There is one major problem, though: assigning a > >> scratch relfilenode to the temporary table requires generating an OID, > >> which we currently have no way to allow on the standby. > > > > Why not have an unlogged counter, which resets each system start, using > > same datatype as an oid. There's no necessity for the relfilenode to be > > an actual oid is there? > > > > That way we could use it on standbys also. > > 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. -- 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 |