> Well, you only prepared the DECLARE CURSOR command, you didn't execute
> it --- so there's no cursor, only a prepared statement sitting waiting
> to be used.
>
> Once you execute the DECLARE CURSOR, you should be able to
> describe its
> portal in advance of fetching any rows from it. Or is that not what
> you wanted?
I suspected the behavior you describe for portal but was hoping
that PQdescribePortal will work same way as PQdescribePrepared
work with prepared statement which is what we are using right now.
However, in our current scenario because of large dataset and many
concurrent users we are major performances issues and out of memory
errors in some cases. I am hoping the use of server side cursor will
help in better memory utilization for multiple users situation
and improve initial response (can you comment if this is a valid
assumption - I am sure about the initial response ).
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.
Thanks,
Brijesh