"Jignesh K. Shah" <[EMAIL PROTECTED]> writes:
> Are there any head fixes proposed for it?
It's been fixed in CVS for a month. We just haven't pushed a release yet.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
Tom Lane wrote:
"Jignesh K. Shah" <[EMAIL PROTECTED]> writes:
Are there any head fixes proposed for it?
It's been fixed in CVS for a month. We just haven't pushed a release yet.
Let me try it out and see what I find out in my EAStress workload.
Regards,
Jignesh
--
Sent via p
Are there any head fixes proposed for it?
I am seeing some scaling problems with EAStress which uses JDBC with
8.3.0 and this one could be the reason why I am seeing some problems.. I
will be happy to try it out and report on it.. The setup is ready right
now if someone can point me to a patch
It's pretty easy to test.
prepare the query
and
run explain analyze on the prepared statement.
Dave
On 10-Apr-08, at 5:47 AM, Thomas Burdairon wrote:
Is there any patch available for this one?
I'm encountering troubles with some JDBC queries and I'd like to
test it before asking some help o
Is there any patch available for this one?
I'm encountering troubles with some JDBC queries and I'd like to test
it before asking some help on the JDBC list.
Thanks.
Tom
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.pos
On Wed, Apr 2, 2008 at 2:53 AM, Dave Cramer <[EMAIL PROTECTED]> wrote:
> I for one would be very interested in the JDBCBench code.
OK, I didn't make anything fancy, I just fixed the problem I
encountered when profiling Sequoia (I mostly used it as an injector).
I'll post the code tomorrow if I c
Guillaume,
I for one would be very interested in the JDBCBench code.
Dave
On 1-Apr-08, at 8:35 PM, Guillaume Smet wrote:
On Wed, Apr 2, 2008 at 2:05 AM, Greg Smith <[EMAIL PROTECTED]>
wrote:
I'm not sure if all of those changes are net positive for PostgreSQL
though, they weren't last time I
On Wed, Apr 2, 2008 at 2:05 AM, Greg Smith <[EMAIL PROTECTED]> wrote:
> I'm not sure if all of those changes are net positive for PostgreSQL
> though, they weren't last time I played with this.
I fixed most of the bugs of JDBCBench I found when I benchmarked
Sequoia a long time ago. Totally forg
On Tue, 1 Apr 2008, Guillaume Smet wrote:
A good answer is probably to plan optional JDBC benchmarks in the
benchfarm design - not all people want to run Java on their boxes but
we have servers of our own to do so.
The original pgbench was actually based on an older test named JDBCbench.
That
On Tue, 01 Apr 2008 16:06:01 +0200, Tom Lane <[EMAIL PROTECTED]> wrote:
Dave Cramer <[EMAIL PROTECTED]> writes:
Was the driver ever changed to take advantage of the above strategy?
Well, it's automatic as long as you use the unnamed statement. About
all that might need to be done on the clie
So if I write
conn.prepareStatement("select col from table where col like ?")
then setString(1,'hello%')
The driver will do
prepare foo as select col from table where col like $1
and then
execute foo('hello%')
this will take advantage of the strategy automatically ?
If so this should be ch
Am 01.04.2008 um 13:14 schrieb Dave Cramer:
On 1-Apr-08, at 6:25 AM, Michael Paesold wrote:
Am 01.04.2008 um 01:26 schrieb Tom Lane:
While testing the changes I was making to Pavel's EXECUTE USING
patch
to ensure that parameter values were being provided to the planner,
it became painfully
Dave Cramer <[EMAIL PROTECTED]> writes:
> Was the driver ever changed to take advantage of the above strategy?
Well, it's automatic as long as you use the unnamed statement. About
all that might need to be done on the client side is to use unnamed
statements more often in preference to named ones
On 1-Apr-08, at 6:25 AM, Michael Paesold wrote:
Am 01.04.2008 um 01:26 schrieb Tom Lane:
While testing the changes I was making to Pavel's EXECUTE USING patch
to ensure that parameter values were being provided to the planner,
it became painfully obvious that the planner wasn't actually *doin
Am 01.04.2008 um 01:26 schrieb Tom Lane:
While testing the changes I was making to Pavel's EXECUTE USING patch
to ensure that parameter values were being provided to the planner,
it became painfully obvious that the planner wasn't actually *doing*
anything with them. For example
execut
On Tue, Apr 1, 2008 at 8:06 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Yeah, the lack of any formal testing of the extended-Query protocol
> is a real problem. I'm not sure of a good fix, but it bears some
> thinking about. Not only do we not have an automated way to notice
> if we broke funct
"Guillaume Smet" <[EMAIL PROTECTED]> writes:
> Another question is how we can be sure it doesn't happen again. The
> easiest way to test this is probably to have a JDBC test testing this
> exact feature in the future benchfarm. Any comment?
Yeah, the lack of any formal testing of the extended-Quer
On Tue, Apr 1, 2008 at 7:35 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Well, it's not like we have never before changed internal APIs in a
> minor update. (There have been security-related cases where we gave
> *zero* notice of such changes.) Nor am I willing to surrender the
> option to do so
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> If anyone squawks we could think about a
>> faster update ...
> That assumes that someone working on using the planner hooks will read
> this thread - which might be reasonable - I guess they number of likely
> users is fairly small
Tom Lane wrote:
The main reason I wanted to make some noise about this is to find out
if anyone is actually trying to call eval_const_expressions (or
relation_excluded_by_constraints, which it turned out needed to change
also) from 8.3 add-on code. If anyone squawks we could think about a
fast
Stephen Frost <[EMAIL PROTECTED]> writes:
> * Tom Lane ([EMAIL PROTECTED]) wrote:
>> Still, the performance regression here is bad enough that I think there
>> is little choice. Comments/objections?
> I agree that we should update stable to fix this performance regression,
> given the gravity of
* Tom Lane ([EMAIL PROTECTED]) wrote:
> The fix is simple: add PlannerInfo to eval_const_expressions's
> parameter list, as was done for estimate_expression_value. I am
> slightly hesitant to do this in a stable branch, since it would break
> any third-party code that might be calling that functio
While testing the changes I was making to Pavel's EXECUTE USING patch
to ensure that parameter values were being provided to the planner,
it became painfully obvious that the planner wasn't actually *doing*
anything with them. For example
execute 'select count(*) from foo where x like $1'
23 matches
Mail list logo