On Tue, Aug 16, 2016 at 8:03 PM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
> On 8/16/16 11:59 AM, Robert Haas wrote:
> ...
>>
>> That doesn't really solve the problem, because OTHER backends won't be
>> able to see them. So, if I create a fast temporary table in one
>> session that depends on a permanent object, some other session can
>> drop the permanent object. If there were REAL catalog entries, that
>> wouldn't work, because the other session would see the dependency.
>
> Some discussion about TEMP functions is happening on -general right now, and
> there's other things where temp objects are good to have, so it'd be nice to
> have a more generic fix for this stuff. Is the idea of "partitioning" the
> catalogs to store temp objects separate from permanent fatally flawed?
I wouldn't say it's fatally flawed. But you might need a
world-renowned team of physicians working round the clock for days in
a class 1 trauma center to save it. If you imagine that you have a
permanent pg_class which holds permanent tables and a temporary
pg_class per-backend which stores temporary tables, then you very
quickly end up with the same deadly flaw as in Aleksander's design:
other backends cannot see all of the dependency entries and can drop
things that they shouldn't be permitted to drop. However, you could
have a permanent pg_class which holds the records for permanent tables
and an *unlogged* table, say pg_class_unlogged, which holds records
for temporary tables. Now everybody can see everybody else's data,
yet we don't have to create permanent catalog entries. So we are not
dead. All of the temporary catalog tables vanish on a crash, too, and
in a very clean way, which is great.
However:
1. The number of tables for which we would need to add a duplicate,
unlogged table is formidable. You need pg_attribute, pg_attrdef,
pg_constraint, pg_description, pg_type, pg_trigger, pg_rewrite, etc.
And the backend changes needed so that we used the unlogged copy for
temp tables and the permanent copy for regular tables is probably
really large.
2. You can't write to unlogged tables on standby servers, so this
doesn't help solve the problem of wanting to use temporary tables on
standbys.
3. While it makes creating temporary tables a lighter-weight
operation, because you no longer need to write WAL for the catalog
entries, there's probably still substantially more overhead than just
stuffing them in backend-local RAM. So the performance benefits are
probably fairly modest.
Overall I feel like the development effort that it would take to make
this work would almost certainly be better-expended elsewhere. But of
course I'm not in charge of how people who work for other companies
spend their time...
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
