any plans to support this new PG 9.2 feature?
any plans to support this new PG 9.2 feature?
http://www.postgresql.org/docs/9.2/stat ... -mode.html
Been waiting for this for a long time, prior to this PostgreSQL would return the entire
result sent which on large queries was super slow.
Been waiting for this for a long time, prior to this PostgreSQL would return the entire
result sent which on large queries was super slow.
Re: any plans to support this new PG 9.2 feature?
Hello
You can leave a suggestion to implement such functionality at our UserVoice page ( http://devart.uservoice.com/forums/1046 ... postgresql ), and the more users vote for your suggestion, the faster we implement the functionality.
You can leave a suggestion to implement such functionality at our UserVoice page ( http://devart.uservoice.com/forums/1046 ... postgresql ), and the more users vote for your suggestion, the faster we implement the functionality.
Re: any plans to support this new PG 9.2 feature?
hm,
i ask me: what is the differnece to cursor fetch? this feature is working fine with DevArt.
anyone knows some documentation where i can read that?
daniel.
i ask me: what is the differnece to cursor fetch? this feature is working fine with DevArt.
anyone knows some documentation where i can read that?
daniel.
Re: any plans to support this new PG 9.2 feature?
hello,
Please describe in more detail what you mean by "differnece to cursor fetch"?
Please describe in more detail what you mean by "differnece to cursor fetch"?
Re: any plans to support this new PG 9.2 feature?
Cursor fetch does not return one row at a time, it returns the entire result set as far as I remember, prior to 9.2 postgresql could not return 1 row at a time from a function etc and
that could cause slowness issues because if the result set was large you had to wait for the entire thing to be transferred to your client. With the one row at a time your UI can start updating immediately.
that could cause slowness issues because if the result set was large you had to wait for the entire thing to be transferred to your client. With the one row at a time your UI can start updating immediately.
Re: any plans to support this new PG 9.2 feature?
Hello,
For the time being, PgDAC doesn't support this functionality. We added your suggestion to our roadmap, however, we cannot nominate the exact terms of the implementation, this will depend on the number of voices at Uservoice.
For the time being, PgDAC doesn't support this functionality. We added your suggestion to our roadmap, however, we cannot nominate the exact terms of the implementation, this will depend on the number of voices at Uservoice.
Re: any plans to support this new PG 9.2 feature?
no thats not right. cursor fetch returns as much rows as you say.snorkel wrote:Cursor fetch does not return one row at a time, it returns the entire result set as far as I remember, prior to 9.2 postgresql could not return 1 row at a time from a function etc and
that could cause slowness issues because if the result set was large you had to wait for the entire thing to be transferred to your client. With the one row at a time your UI can start updating immediately.
http://www.postgresql.org/docs/9.2/stat ... rsors.html
PgDAC supports this feature very well. The problem with CursorFetch is that you always need a transaction.
I'm confused why there is a new feature "single row mode" - still can't see a difference. (AlexP i mean the difference of the feature on PostgreSQL-side, not on DevArt)
Re: any plans to support this new PG 9.2 feature?
Hello,
Yes, for the time being, line-by-line reading can be organized by means of PgDAC using the FetchAll (set to False) and FetchRows (set to 1) properties. To work with refcursor, independently on these properties values, a transaction must be started. But we cannot ensure similarity of this behaviour to the new functionality, since we haven't fully explored the new PostgreSQL 9.2 features.
Yes, for the time being, line-by-line reading can be organized by means of PgDAC using the FetchAll (set to False) and FetchRows (set to 1) properties. To work with refcursor, independently on these properties values, a transaction must be started. But we cannot ensure similarity of this behaviour to the new functionality, since we haven't fully explored the new PostgreSQL 9.2 features.
Re: any plans to support this new PG 9.2 feature?
Yes, thats what i mean.
I can't find any informations about the differences of this 2 PostgreSQL features as well.
Have a nice evening.
I can't find any informations about the differences of this 2 PostgreSQL features as well.
Have a nice evening.