Re: [INTERFACES] Back end memory consumption (was Front end memory consumption in SELECT)
От | Douglas Thomson |
---|---|
Тема | Re: [INTERFACES] Back end memory consumption (was Front end memory consumption in SELECT) |
Дата | |
Msg-id | 199912022330.KAA03178@mugca.cc.monash.edu.au обсуждение исходный текст |
Ответ на | Re: [INTERFACES] Front end memory consumption in SELECT (Douglas Thomson <dougt@mugc.cc.monash.edu.au>) |
Ответы |
Re: [INTERFACES] Back end memory consumption (was Front end memory consumption in SELECT)
Re: [INTERFACES] Back end memory consumption (was Front end memory consumption in SELECT) |
Список | pgsql-interfaces |
A few weeks ago I reported a problem I was having with front end memory consumption in SELECT, and Tom's suggestion about using a cursor solved that problem very nicely at the front end. However, my front and back end processes are running on the same server, and I have just noticed that the back end process swells to the total size of all the tables involved in my query for the duration of the SELECT (or is it the duration of the declared cursor now?). To summarise the situation: - back end processes on my system are usually about 3M (PostgreSQL 6.5.1, Debian slink, Intel) - I am attempting a join on 9 tables, using a cursor to fetch the selected data - I am only selecting a tiny fraction of the total data - I am running in serializable mode if it matters - the files used to store my tables (including associated keys and indexes etc) take just under 17M on disk - the back end process grows to over 20M while processing my query This is a serious concern, because 17M is just some sample data, and will eventually be much larger. Any hints for ways of limiting back end memory consumption (hopefully to something constant rather than something proportional to the tables sizes)? Doug.
В списке pgsql-interfaces по дате отправления: