Neil Conway wrote: >On Thu, 11 Apr 2002 16:25:24 +1000 >"Ashley Cambrell" <[EMAIL PROTECTED]> wrote: > >>What are the chances that the BE/FE will be altered to take advantage of >>prepare / execute? Or is it something that will "never happen"? >> > >Is there a need for this? The current patch I'm working on just >does everything using SQL statements, which I don't think is >too bad (the typical client programmer won't actually need to >see them, their interface should wrap the PREPARE/EXECUTE stuff >for them). > I remember an email Hannu sent (I originally thought Tome sent it but I found the email*) that said postgresql spends a lot of time parsing sql (compared to oracle), so if the BE/FE and libpq were extended to support pg_prepare / pg_bind, then it might make repetitive queries quicker.
"if we could save half of parse/optimise time by saving query plans, then the backend performance would go up from 1097 to 100000/(91.1-16.2)=1335 updates/sec." Hannu's email doesn't seem to be in google groups, but it's titled "Oracle vs PostgreSQL in real life" (2002-03-01). I can attach it if people can't find it. > >On the other hand, there are already a few reasons to make some >changes to the FE/BE protocol (NOTIFY messages, transaction state, >and now possibly PREPARE/EXECUTE -- anything else?). IMHO, each of >these isn't worth changing the protocol by itself, but perhaps if >we can get all 3 in one swell foop it might be a good idea... > Passing on a possible 1/3 speed improvement doesn't sound like a bad thing.. :-) Hannu: You mentioned that you already had an experimental patch that did it? Was that the same sort of thing as Neil's patch (SPI), or did it include a libpq patch as well? > >Cheers, > >Neil > Ashley Cambrell ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html