Re: Issue with PQdescribePortal to describe a select cursor
От | Brijesh Shrivastav |
---|---|
Тема | Re: Issue with PQdescribePortal to describe a select cursor |
Дата | |
Msg-id | 5774D66D5EC83645A99B3A905527BB7102933EE7@zipwire.esri.com обсуждение исходный текст |
Ответ на | Re: Issue with PQdescribePortal to describe a select cursor (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-interfaces |
> > "Brijesh Shrivastav" <Bshrivastav@esri.com> writes: > > My problem in executing a portal before I can describe is the way > > our client api interface is defined. Typically user sends us a query > > that we prepare and describe before sending the describe output > > back to the client. In next step user provides us with any input > > parameter data for the sql and ask us to execute the query. This > > system works well with PQprepare/PQdescribePrepared but doesn't > > give me the advantage of a portal. One option that will have a > > performance penalty will be to prepare the statement > without creating > > a portal during initial query so I can send describe results back > > to the client and only create the portal during the execute. I will > > pay the cost of preparing query twice though I can set LIMIT to 0 > > for the initial query to possibly reduce the prepare time. > > You seem to be confusing preparing a query with executing it. LIMIT 0 > isn't going to save any prepare time. That is true, LIMIT 0 won't help me here. I was just trying to think of some way where I can force a simple plan that takes less time to prepare since I am going to disregard that plan in any case. Brijesh
В списке pgsql-interfaces по дате отправления: