On Tue, Oct 19, 2010 at 4:12 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> ... and relpages and reltuples ...
Those are hardly very convincing examples. Neither are values that
need to be updated in transactions and neither relates to the
definition of the table. They could be moved from pg_class to some
internal data structure without imposing any real problems.
I guess what I'm saying is that mixing the low-level data about the
storage with the high-level schema information in a single table is
what painted us into this corner. If we separate those two then we
have a natural separation between the data that can be read-only
global for all temporary tables and the data that's read-write and
stored in memory.
Now that I've written that though I wonder what happens when you
modify the schema. Do you have to wait unti all transactions are done
with their temporary copies of the table?
> it's really not going to be that easy
> to have a table that isn't described in pg_class. Which the structure
> you're describing isn't. There might be a template for it in pg_class,
> but that's something entirely different.
>
>> In the case of tables created locally on a slave, well, that's more
>> complicated.
>
> I think they're more alike than you think. If we had the infrastructure
> to do local temp tables this way, it'd be pretty easy to use that to
> instantiate per-backend copies of global temp tables. (The global
> entities would be templates, not actual tables.)
Sure, but I think the idea was that you should be able to create
temporary tables from whole cloth on the slave. Since they're local to
the backend they never have to be stored on disk so logically from the
user's point of view it seems like it should be possible.
--
greg