Re: [INTERFACES] More protocol discussion: breaking down query processing
От | Greg Stark |
---|---|
Тема | Re: [INTERFACES] More protocol discussion: breaking down query processing |
Дата | |
Msg-id | 87smsuvzob.fsf@stark.dyndns.tv обсуждение исходный текст |
Ответ на | More protocol discussion: breaking down query processing (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Yay, this would be very cool. Two small things to keep in mind during design, though they aren't necessarily things needed in a first implementation: 1) There's an alternate form of the execute step that provides an array of sets of bind values and executes the originalquery many times, once for each set of bind values. This is essential for performing large batch data updates efficiently.Usually this would be for insert or update statements, I'm not sure if other databases even allow it for selectqueries, though I could imagine it being useful. 2) There could be an option to delay optimization until the bind stage. This would be an option the interface layer or applicationwould provide in cases where either the query is unlikely to be repeated (such as if it was called from a higherlevel function that does the parse and bind step together) or is likely to be heavily affected by the input parameters(if the application programmer knows something special about the data distribution). Oh, and I'm sure it's obvious, but there would be no problem having multiple open cursors, right? So an application could prepare all the queries it's going to ever execute during initialization, then execute query 1, and for each row it fetches from 1 execute query 2 with calculated values. For some reason this isn't working with the PHP interface currently, I assume that's just a bug in the PHP driver, not in libpq. -- greg
В списке pgsql-hackers по дате отправления: