Re: [HACKERS] [QUESTIONS] lo_write cannot > 640Kb? memory leaks?
От | Chul Su Park |
---|---|
Тема | Re: [HACKERS] [QUESTIONS] lo_write cannot > 640Kb? memory leaks? |
Дата | |
Msg-id | 199805212047.FAA27332@bwg02.kek.jp обсуждение исходный текст |
Ответ на | Re: [HACKERS] [QUESTIONS] lo_write cannot > 640Kb? memory leaks? (dg@illustra.com (David Gould)) |
Ответы |
Re: [HACKERS] [QUESTIONS] lo_write cannot > 640Kb? memory leaks?
|
Список | pgsql-hackers |
Hi, > Have you tried increasing the number of postgres buffer cache buffers? I am > speculating that the lo_write() is using these buffers but perhaps not > flushing them. As the default configuration has way too few buffers anyway > this might be the problem. Could you try increasing the buffers to say 1024 or > so and rerun your test and post the results? > > -dg Thanks for your reply, but as I posted I tested many different size of buffers in lotest.c, e.g. 1Kb, 4Kb, 8Kb, 9Kb, 10Kb, 16Kb, 32Kb, 64Kb, 640Kb, 1Mb, 10Mb, ... or your "cache" or "buffer" size have some diffferent meaning? but lo_write cannot exceed 640kb always, only open/write(less than 640kb)/close looping OR open LOOP lo_write(buffer<640Kb)) , lo_lseek to SEEK_END, write, ... seems to solve this problem(as in my last email), and I found that 16Kb buffer seems to be the optimal buffer size for the SPEED(not 8Kb) for network & socket connections why?... and I think that above lo_lseek write loop is not a real solution, because lo_read seems does not have such defects(but 16kb buffer seems to be the optimal size also), there must be some problems in lo_write or buffer managing... does anybody have some guess or fixes? c.s.park
В списке pgsql-hackers по дате отправления: