Re: Vacuuming leaked temp tables (once again)
От | Simon Riggs |
---|---|
Тема | Re: Vacuuming leaked temp tables (once again) |
Дата | |
Msg-id | 1215819708.4051.1678.camel@ebony.2ndQuadrant обсуждение исходный текст |
Ответ на | Re: Vacuuming leaked temp tables (once again) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Vacuuming leaked temp tables (once again)
|
Список | pgsql-hackers |
On Fri, 2008-07-11 at 17:26 -0400, Tom Lane wrote: > Simon Riggs <simon@2ndquadrant.com> writes: > > So it would seem that we need a way of handling temp tables that doesn't > > rely on catalog entries at all. > > That's a complete non-starter; I need go no farther than to point out > that it would break clients that expect to see their temp tables > reflected in pg_class and so forth. What does the SQL Standard say about the Information Schema I wonder/ > There's been some idle musing in the past about causing pg_class and > friends to have inheritance-child tables that are "temp", both in the > sense of being backend-local and of not having guaranteed storage, > and arranging to store the rows needed for a backend's temp tables > in there. There's still a long way to go to make that happen, but > at least it would be reasonably transparent on the client side. OK, very cool if we could make it work. I realised it would have to apply all the way through to pg_statistic. Brain dump a little more, while we're on the subject? This aspect is something I've not spent any time on yet, so even a few rungs up the ladder will help lots. Thanks. -- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
В списке pgsql-hackers по дате отправления: