On Wed, Apr 25, 2012 at 4:55 AM, Noah Misch <noah@leadboat.com> wrote:
> 1. High catalog turnover in rapid create/drop workloads. Heavy temporary
> table users often need to REINDEX relation-oriented catalogs. Hot standby
> cannot assign OIDs or modify system catalogs at all.
> 4. sinval traffic from every CREATE TEMP TABLE et al.
> 5. CREATE TEMP TABLE records AccessExclusiveLock in the global lock table.
> I do not see a clean behind-the-scenes fix for points 1, 4 and 5. We can
> resolve those by adding a new variety of temporary table, one coincidentally
> matching the SQL standard's notion of a temporary table. The developer will
> declare it once, after which all sessions observe it as an initially-empty
> table whose contents remain local to the session.
The rest of your post is very good and I'm excited. This part doesn't
work for me.
I don't see how introducing a new type of temp table solves this
problem. How would the developer declare this in HS? How would it then
be globally visible without using global OIDs, causing sinval and
using global locks? This feels like a suggestion from somewhere else
grafted onto your proposal. I'm not against introducing a new type of
temp table, I just think it is orthogonal to the OT.
For me, the solutions are
4. Invent a "linval" - an invalidation that always stays local
5. invent a LocalRelationLock that takes AccessExclusiveLock but never
goes to the global lock table.
So those aspects stay completely in local memory.
1. is a little harder. I suggest we have a range of say 16384 OIDs
reserved for use by temporary relations. If that range is used up we
do then move to using real global Ids, though that is code we'll
almost never need, so it would be acceptable to restrict HS sessions
to only ever use 16384 temp tables concurrently in one session.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
