2013/1/23 Robert Haas <robertmhaas@gmail.com>:
> On Wed, Jan 23, 2013 at 8:10 AM, Dimitri Fontaine
> <dimitri@2ndquadrant.fr> wrote:
>> Really, live DDL is not that frequent, and when you do that, you want
>> transparent replanning. I can't see any use case where it's important to
>> be able to run DDL in a live application yet continue to operate with
>> the old (and in cases wrong) plans.
>
> I agree with that, but I think Tom's concern is more with the cost of
> too-frequent re-planning. The most obvious case in which DDL might be
> frequent enough to cause an issue here is if there is heavy use of
> temporary objects - sessions might be rapidly creating and dropping
> objects in their own schemas. It would be unfortunate if that forced
> continual replanning of queries in other sessions. I think there
> could be other cases where this is an issue as well, but the
> temp-object case is probably the one that's most likely to matter in
> practice.
probably our model is not usual, but probably not hard exception
almost all queries that we send to server are CREATE TABLE cachexxx AS
SELECT ...
Tables are dropped, when data there are possibility so containing data
are invalid. Probably any replanning based on DDL can be very
problematic in our case.
Number of tables in one database can be more than 100K.
Regards
Pavel
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
