Greg Stark <stark@enterprisedb.com> wrote:
> On Wed, Apr 29, 2009 at 6:42 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I agree with Kevin's objection that you are unfairly raising the
>> bar for this feature by demanding a performance improvement to go
>> along with a functionality change.
>
> I think having the feature is making a promise that we can't keep.
> Having a feature which meets the letter of the rules but fails to
> actually work as users have a right to expect is going to trap
> people unaware that they're writing code that works in testing but
> will never scale.
But the scaling issues are there already with temp tables. This
actually makes it better, not worse, because the table can be
materialized once per session, not once per request.
>> The use-case for this feature is to
>> simplify application logic by allowing apps to assume that a temp
>> table exists without having to create it at the start of a session.
>> That's particularly handy in connection-pooling scenarios, for
>> instance. Currently, you have to have some sort of "if exists"
>> check, and you pay just as much in catalog thrashing as you would
>> if the feature was present without any catalog optimization.
>
> That seems like a trivial little annoyance.
And a potentially large performance booster.
>> It would be great to find a way to avoid the catalog thrashing,
>> but I completely disagree with a point of view that says we can't
>> have this without solving that first. It's an improvement on the
>> current state of affairs anyway.
>
> Not if it promises something we can't deliver. My claim is that the
> whole point of having a persistent catalog definition is *precisely*
> to avoid the catalog thrashing and that's obvious to users who would
> be using this feature.
I've re-read the spec on this several times now, and I can't see where
that is implied.
> I still maintain that this feature is not primarily about programmer
> convenience, but rather comes with an expectation that the schema
> definition is being given in advance so that the database doesn't
> have to incur the costs of issuing the ddl for every session.
I think many would be satisfied not to have those costs on every
*request* on the connection.
-Kevin
