Re: Large # of rows in query extremely slow, not using
От
Kris Jurka
Тема
Re: Large # of rows in query extremely slow, not using
Дата
Msg-id
Pine.BSO.4.56.0409231840280.18935@leary.csoft.net
Ответ на
Re: Large # of rows in query extremely slow, not using index (Stephen Crowley)
Список
Дерево обсуждения
Large # of rows in query extremely slow, not using index Stephen Crowley <stephen.crowley@gmail.com>
Re: Large # of rows in query extremely slow, not using Rod Taylor <rbt@rbt.ca>
Re: Large # of rows in query extremely slow, not using Markus Schaber <schabios@logi-track.com>
Re: Large # of rows in query extremely slow, not using Pierre-Frédéric Caillaud<lists@boutiquenumerique.com>
Re: Large # of rows in query extremely slow, not using Stephen Crowley <stephen.crowley@gmail.com>
Re: Large # of rows in query extremely slow, not using Josh Berkus <josh@agliodbs.com>
Re: Large # of rows in query extremely slow, not using "Joshua D. Drake" <jd@commandprompt.com>
Re: Large # of rows in query extremely slow, not using Manfred Koizar <mkoi-pg@aon.at>
Re: Large # of rows in query extremely slow, not using Stephen Crowley <stephen.crowley@gmail.com>
Re: Large # of rows in query extremely slow, not using Manfred Koizar <mkoi-pg@aon.at>
Re: Large # of rows in query extremely slow, not using index Tom Lane <tgl@sss.pgh.pa.us>
Re: Large # of rows in query extremely slow, not using index Stephen Crowley <stephen.crowley@gmail.com>
Re: Large # of rows in query extremely slow, not using index Tom Lane <tgl@sss.pgh.pa.us>
Re: Large # of rows in query extremely slow, not using index Stephen Crowley <stephen.crowley@gmail.com>
Re: Large # of rows in query extremely slow, not using Kris Jurka <books@ejurka.com>
Re: Large # of rows in query extremely slow, not using index Stephen Crowley <stephen.crowley@gmail.com>
Re: Large # of rows in query extremely slow, not using Kris Jurka <books@ejurka.com>
On Thu, 23 Sep 2004, Stephen Crowley wrote: > Thanks for the explanation. So what sort of changes need to be made to > the client/server protocol to fix this problem? The problem is that there is no way to indicate why you are using a particular statement in the extended query protocol. For the JDBC driver there are two potential reasons, streaming a ResultSet and using a server prepared statement. For the streaming as default case you desire there needs to be a way to indicate that you don't want to create a generic server prepared statement and that this query is really just for one time use, so it can generate the best plan possible. Additionally you can only stream ResultSets that are of type FORWARD_ONLY. It would also be nice to be able to specify scrollability and holdability when creating a statement and the offset/direction when streaming data from a scrollable one. Kris Jurka
В списке pgsql-performance по дате отправления
От: Stephen Crowley
Дата: