Re: statement caching proof of concept redux
От | peter royal |
---|---|
Тема | Re: statement caching proof of concept redux |
Дата | |
Msg-id | 7E546DC2-9F18-4F26-8E7C-5AC8423065B8@pobox.com обсуждение исходный текст |
Ответ на | Re: statement caching proof of concept redux (Dave Cramer <pg@fastcrypt.com>) |
Список | pgsql-jdbc |
On Mar 1, 2007, at 5:59 PM, Dave Cramer wrote: > Since then we have some real results so I'd like to solicit ideas > from the group about implementing statement caching. > > First and foremost it would be off by default and have to be > explicitly turned on. After that I'm wondering about parameters > which would affect resources. Would we want connection/database/ > driver connection limits ? Do we do this by number of prepared > statements ? Overall memory consumption ? Then there is aging of > cached statements; any ideas on how to age them? Will they need to > be invalidated after so much time ? Are the patch files from June still fully applicable to the latest trunk code? (lazy question for sure, I could just apply-and-test m'self). I think caching policies could be fully separate from the implementation? I mean, in most applications that need this for performance reasons should have some sort of caching infrastructure already, and being able to plug into that would be great. If there was a way to set a 'StatementCache' implementation onto the DataSource impl, that'd be ideal. (Yes, this is me half-volunteering). Then, we can make up some default policies, but ultimately anything count/memory consumption is up to the users? We'd need to get some people running with the code to be able to make some decisions about sensible defaults. But anyone using pgsql should be familiar with tuning numbers for optimal performance anyways :) -pet -- (peter.royal|osi)@pobox.com - http://fotap.org/~osi
Вложения
В списке pgsql-jdbc по дате отправления: