Re: [PERFORM] join over 12 tables takes 3 secs to plan

Neil:

Thanks for the feedback.  I've attached my original text to this note 
and re-posted it back to pgsql-jdbc to make sure that they are aware of 
them.  I look forward to this new and improved server-side preparation.

Charlie

Neil Conway wrote:

>On Sun, 2003-01-12 at 10:52, Charles H. Woloszynski wrote:
>  
>
>>As I understand it, the functions I am waiting for are targeted into 7.4 
>>(but I'd love to see them early and do some testing of those for the 
>>community).
>>    
>>
>
>Ok -- those are pretty much all features on the JDBC side of things (not
>the backend implementation of PREPARE/EXECUTE). I'm not sure how much of
>that is planned for 7.4: if you haven't talked to the JDBC guys about
>it, they may not be aware of your comments.
>
>Cheers,
>
>Neil
>  
>
Charles H. Woloszynski wrote:

> Neil:
>
> I think that general use of this feature should be enabled using the 
> URL, not with an API call.  We use a JDBC connection pool and it will 
> help tremendously to have the pool set to user server-side preparing 
> without having to downcast the connection to a PG connection (which I 
> think is an issue because of the facade in our connection pool code). 
> The second item is that of compatibility.  If the new code cannot 
> handle all statements (eg. something with a semi in it) and disable 
> the generation of a 'prepare' then we cannot count on the URL 
> functionality. As I understand it, the programmer is required 
> currently to enable/disable the server-side functionality by hand and 
> only when the statement to be prepared is not composite (statement1; 
> statement2; statement2).
>
> But in our real-world application space, we use a connection pool with 
> a facade, so getting to the actual connection to enable this is 
> problematic (and forces postgresql-specific coding into our framework 
> where it is not particularly welcome).  If we overcame this issue, we 
> would then need to hand-manage the enable/disable to only be used when 
> the statement is appropriately formulated (e.g., no semicolons in the 
> statement).
>
> If we could get URL enabling and auto-detection of statements that 
> won't work (and hence disable the enabled function for these 
> functions), I think we have a solution that can be deployed into 
> 'generic' app server environments with just configuration changes.  
> That is, an operations person could enable this feature and monitor 
> its impact on performance to see if/how it helps.  That is a BIG win 
> (at least to me) and a HUGE marketing item.  I'd love to test MySQL 
> with some joins over JDBC with PostgreSQL with some joins using 
> prepared statements and be able to demonstrate the big improvement 
> that this makes.
>
> As I understand it, the functions I am waiting for are targeted into 
> 7.4 (but I'd love to see them early and do some testing of those for 
> the community).




-- 


Charles H. Woloszynski

ClearMetrix, Inc.
115 Research Drive
Bethlehem, PA 18015

tel: 610-419-2210 x400
fax: 240-371-3256
web: www.clearmetrix.com