Re: Postgres eats up memory when using cursors
От | Denis Perchine |
---|---|
Тема | Re: Postgres eats up memory when using cursors |
Дата | |
Msg-id | 01030123253806.00608@dyp.perchine.com обсуждение исходный текст |
Ответ на | Re: Postgres eats up memory when using cursors (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-general |
> Looks pretty simple to me too; I was expecting that you were doing > expression evaluations or some such. I cannot reproduce any backend > leakage in this query, either in 7.0.* or current sources. I did > > create table senders (email text, first_name text, last_name text); > \copy senders from 'todo' -- some junk data > create index sendersi on senders(email); > insert into senders select * from senders; -- repeat a few times > > begin; > explain > declare senders_c cursor for select email, first_name, last_name > from senders order by email; > NOTICE: QUERY PLAN: > > Index Scan using sendersi on senders (cost=0.00..102.78 rows=2161 > width=36) > > end; > > then made a script file > > begin; > declare senders_c cursor for select email, first_name, last_name > from senders order by email; > > fetch 10000 from senders_c > \g zzz > fetch backward 10000 from senders_c > \g zzz > fetch 10000 from senders_c > \g zzz > fetch backward 10000 from senders_c > \g zzz > fetch 10000 from senders_c > \g zzz > ... repeat a few thousand times ... > > end; > > Backend memory usage is absolutely rock steady. > > Curiously, there does seem to be a leak in psql, or possibly libpq, > when running this script. It's per-query not per-tuple, so it's > easier to see if you make the fetches shorter: > > fetch 100 from senders_c > \g zzz > fetch backward 100 from senders_c > \g zzz > > Repeating these like mad, psql grows about 1Kb/sec on my machine. > This occurs with current sources but NOT with 7.0.2 psql. Peter, > any thoughts about that? Actually you should also consider that there is really intensive inserts happend at the same time. Cursor is closed in 3-4 days only... -- Sincerely Yours, Denis Perchine ---------------------------------- E-Mail: dyp@perchine.com HomePage: http://www.perchine.com/dyp/ FidoNet: 2:5000/120.5 ----------------------------------
В списке pgsql-general по дате отправления: