From: | peter royal <peter(dot)royal(at)pobox(dot)com> |
---|---|
To: | List <pgsql-jdbc(at)postgresql(dot)org> |
Subject: | Re: statement caching proof of concept redux |
Date: | 2007-03-05 06:22:54 |
Message-ID: | 7E546DC2-9F18-4F26-8E7C-5AC8423065B8@pobox.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | YourSoft | 2007-03-05 10:56:50 | JDBC driver bug? |
Previous Message | Valery Meshkov | 2007-03-04 19:00:08 | BUG #3106: A problem with escaping table name pattern for DatabaseMetaData.getColumns() |