Re: Performance with temporary table
От | samantha mahindrakar |
---|---|
Тема | Re: Performance with temporary table |
Дата | |
Msg-id | f0c828c40804091641w36b98fb9o7a4019f576d53ec6@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Performance with temporary table (Decibel! <decibel@decibel.org>) |
Ответы |
Re: Performance with temporary table
|
Список | pgsql-performance |
Hi The reason for using the temporary table is that i need this data buffered somewhere so that i can use it for later computation. And the fact that for each imputation i need to have historical data from 10 previous weeks makes it necessary to create something that can hold the data. However once the computation is done for each record i wouldn't need that historical data for that record. I Would be moving on to the next record and find its own historical data. Is there any way i can avoid using temp table? Samantha On Wed, Apr 9, 2008 at 4:09 PM, Decibel! <decibel@decibel.org> wrote: > On Apr 8, 2008, at 2:43 PM, Alvaro Herrera wrote: > > > samantha mahindrakar escribió: > > > > > Well instead of creating a temp table everytime i just created a > > > permanant table and insert the data into it everytime and truncate it. > > > I created indexes on this permanent table too. This did improve the > > > performance to some extent. > > > > > > Does using permanant tables also bloat the catalog or hinder the > performance? > > > > > > > In terms of catalog usage, permanent tables behave exactly the same as > > temp tables. > > > > True, but the point is that you're not bloating the catalogs with thousands > of temp table entries. > > I agree with others though: it certainly doesn't sound like there's any > reason to be using temp tables here at all. This sounds like a case of > trying to apply procedural programming techniques to a database instead of > using set theory (which generally doesn't work well). > -- > Decibel!, aka Jim C. Nasby, Database Architect decibel@decibel.org > Give your computer some brain candy! www.distributed.net Team #1828 > > >
В списке pgsql-performance по дате отправления: