Re: join over 12 tables takes 3 secs to plan
От | Charles H. Woloszynski |
---|---|
Тема | Re: join over 12 tables takes 3 secs to plan |
Дата | |
Msg-id | 3E218F2B.8030107@clearmetrix.com обсуждение исходный текст |
Ответ на | Re: join over 12 tables takes 3 secs to plan (Neil Conway <neilc@samurai.com>) |
Список | pgsql-performance |
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). Charlie Neil Conway wrote: >On Fri, 2003-01-03 at 17:16, Charles H. Woloszynski wrote: > > >>I think the functionality is starting to become real, but it looks like >>it is starting with some limitations that might restricts its use from >>be maximally realized until 7.4 (or beyond). >> >> > >Specifically, which limitations in this feature would you like to see >corrected? > >Cheers, > >Neil > > -- Charles H. Woloszynski ClearMetrix, Inc. 115 Research Drive Bethlehem, PA 18015 tel: 610-419-2210 x400 fax: 240-371-3256 web: www.clearmetrix.com
В списке pgsql-performance по дате отправления: