Greg Stark <st...@enterprisedb.com> writes:
> I don't understand what you mean by a cost once per request. You only
> have to create the temporary table on the first request. If you can't
> tell which is the first request you only have to test whether it
> exists which doesn't incur the consequences that ddl incurs.
This is all based on utterly-unproven assumptions about relative costs.
In particular, ISTM an additional network round trip or two associated
with testing for/creating a temp table could easily swamp any costs
associated with catalog entry creation. Even if it doesn't,
creating/deleting a few dozen rows in the system catalogs shouldn't
really be something that autovacuum can't deal with. If it were,
we'd be hearing a lot more complaints about the *existing* temp table
feature being unusable. (And yes, I know it's come up once or twice,
but not all that often.)
I'm all for eliminating catalog overheads, if we can find a way to do
that. I don't think that you get to veto implementation of the feature
until we can find a way to optimize it better. The question is not
about whether having the optimization would be better than not having it
--- it's about whether having the unoptimized feature is better than
having no feature at all (which means people have to implement the same
behavior by hand, and they'll *still* not get the optimization).
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
