2014-04-16 10:54 keltezéssel, Boszormenyi Zoltan írta:
2014-01-18 18:08 keltezéssel, Boszormenyi Zoltan írta:
Hi,
Alvaro Herrera wrote:
Boszormenyi Zoltan escribió:
Rebased patches after the regression test and other details were fixed
in the infrastructure part.
This thread started in
2014-01-16 23:42 keltezéssel, Alvaro Herrera írta:
Boszormenyi Zoltan escribió:
Rebased patches after the regression test and other details were fixed
in the infrastructure part.
This thread started in 2010, and various pieces have been applied
already and some others have changed in nature.
Boszormenyi Zoltan escribió:
Rebased patches after the regression test and other details were fixed
in the infrastructure part.
This thread started in 2010, and various pieces have been applied
already and some others have changed in nature. Would you please post a
new patchset, containing
2013-12-21 14:56 keltezéssel, Peter Eisentraut írta:
This patch didn't make it out of the 2013-11 commit fest. You should
move it to the next commit fest (probably with an updated patch)
before January 15th.
Done.
Best regards,
Zoltán Böszörményi
--
--
Zoltán
This patch didn't make it out of the 2013-11 commit fest. You should
move it to the next commit fest (probably with an updated patch)
before January 15th.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
2013-11-12 07:15 keltezéssel, Boszormenyi Zoltan írta:
2013-11-12 07:01 keltezéssel, Noah Misch írta:
On Mon, Nov 11, 2013 at 10:17:54AM +0100, Boszormenyi Zoltan wrote:
The old contents of my GIT repository was removed so you need to
clone it fresh.
2013-10-11 00:16 keltezéssel, Alvaro Herrera írta:
Boszormenyi Zoltan escribió:
2013-09-10 03:04 keltezéssel, Peter Eisentraut írta:
You need to update the dblink regression tests.
Done.
Dude, this is an humongous patch. I was shocked by it initially, but on
further reading, I observed that
On Mon, Nov 11, 2013 at 10:17:54AM +0100, Boszormenyi Zoltan wrote:
The old contents of my GIT repository was removed so you need to
clone it fresh. https://github.com/zboszor/ecpg-readahead.git
I won't post the humongous patch again, since sending a 90KB
compressed file to everyone on the
2013-10-11 00:16 keltezéssel, Alvaro Herrera írta:
Boszormenyi Zoltan escribió:
2013-09-10 03:04 keltezéssel, Peter Eisentraut írta:
You need to update the dblink regression tests.
Done.
Dude, this is an humongous patch.
You *know* that the patch is available in pieces at
Boszormenyi Zoltan escribió:
2013-09-10 03:04 keltezéssel, Peter Eisentraut írta:
You need to update the dblink regression tests.
Done.
Dude, this is an humongous patch. I was shocked by it initially, but on
further reading, I observed that it's only a huge patch which also does
some
Hi,
2013-08-17 13:02 keltezéssel, Boszormenyi Zoltan írta:
[snip, discussion of WHERE CURRENT OF in the ECPG client lib]
I had a second thought about it and the client side caching and
parser behind the application's back seems to be an overkill.
Instead, I propose a different solution, which
You need to update the dblink regression tests.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, 2013-09-04 at 10:06 +0200, Boszormenyi Zoltan wrote:
2013-08-17 12:08 keltezéssel, Boszormenyi Zoltan írta:
I have put the broken up patchset into a GIT tree of mine at GitHub:
https://github.com/zboszor/ecpg-readahead/
but the huge compressed patch is also attached for reference.
2013-08-17 12:08 keltezéssel, Boszormenyi Zoltan írta:
Hi,
I am restarting this old thread... :-)
2012-04-24 10:17 keltezéssel, Michael Meskes írta:
OK, I will implement #2. Another question popped up: what to do
with FETCH ALL? The current readahead window size or temporarily
bumping it to
OK, I will implement #2. Another question popped up: what to do
with FETCH ALL? The current readahead window size or temporarily
bumping it to say some tens of thousands can be used. We may not
know how much is the all records. This, although lowers performance,
saves memory.
I would say
Hi,
2012-04-17 06:48 keltezéssel, Michael Meskes írta:
On Tue, Apr 17, 2012 at 06:02:34AM +0200, Boszormenyi Zoltan wrote:
I listed two scenarios.
1. occasional bump of the readahead window for large requests,
for smaller requests it uses the originally set size
2. permanent bump of the
On Mon, Apr 16, 2012 at 06:24:57AM +0200, Boszormenyi Zoltan wrote:
Yes, just like when the readahead window set to 256, FETCH 1024
will iterate through 4 windows or FETCH 64 iterates through the
same window 4 times. This is the idea behind the readahead window.
Really? It's definitely not the
2012-04-16 18:04 keltezéssel, Michael Meskes írta:
On Mon, Apr 16, 2012 at 06:24:57AM +0200, Boszormenyi Zoltan wrote:
Yes, just like when the readahead window set to 256, FETCH 1024
will iterate through 4 windows or FETCH 64 iterates through the
same window 4 times. This is the idea behind the
On Mon, Apr 16, 2012 at 07:18:07PM +0200, Boszormenyi Zoltan wrote:
OK. I would like to stretch your agreement a little. :-)
...
Yeah, you got a point here.
By the new FETCH request. Instead of the above, I imagined this:
- the runtime notices that the new request is larger than the current
2012-04-17 05:52 keltezéssel, Michael Meskes írta:
On Mon, Apr 16, 2012 at 07:18:07PM +0200, Boszormenyi Zoltan wrote:
OK. I would like to stretch your agreement a little. :-)
...
Yeah, you got a point here.
By the new FETCH request. Instead of the above, I imagined this:
- the runtime
On Tue, Apr 17, 2012 at 06:02:34AM +0200, Boszormenyi Zoltan wrote:
I listed two scenarios.
1. occasional bump of the readahead window for large requests,
for smaller requests it uses the originally set size
2. permanent bump of the readahead window for large requests
(larger than
On Tue, Apr 10, 2012 at 07:56:35PM +0200, Boszormenyi Zoltan wrote:
With the above, it would be possible to use a comma separated list of -r
suboptions, e.g. -r prepare,questionmarks,readahead=16 in one option.
Yes, that sounds like a good plan. But of course it's outside the scope of this
2012-04-16 04:46 keltezéssel, Michael Meskes írta:
On Tue, Apr 10, 2012 at 07:56:35PM +0200, Boszormenyi Zoltan wrote:
With the above, it would be possible to use a comma separated list of -r
suboptions, e.g. -r prepare,questionmarks,readahead=16 in one option.
Yes, that sounds like a good
2012-04-08 19:38 keltezéssel, Michael Meskes írta:
On Sun, Apr 08, 2012 at 06:35:33PM +0200, Boszormenyi Zoltan wrote:
Do you want me to change this or will you do it? I am on holiday
and will be back to work on wednesday.
I don't think waiting till later this week is a real problem.
OK.
On Tue, Apr 10, 2012 at 09:35:21AM +0200, Boszormenyi Zoltan wrote:
So, it's established that a specified READAHEAD N should not
be overridden. Even an explicit READAHEAD 1.
Only a non-decorated cursor can be overridden, even if
a different default readahead window size is specified with
On Tue, Apr 10, 2012 at 10:37:22AM -0400, Noah Misch wrote:
Only a non-decorated cursor can be overridden, even if
a different default readahead window size is specified with
e.g. ecpg -R 8. If ECPGFETCHSZ is not present, 8 will be used,
if ECPGFETCHSZ is present, its value will be used.
2012-04-10 16:55 keltezéssel, Michael Meskes írta:
On Tue, Apr 10, 2012 at 10:37:22AM -0400, Noah Misch wrote:
Only a non-decorated cursor can be overridden, even if
a different default readahead window size is specified with
e.g. ecpg -R 8. If ECPGFETCHSZ is not present, 8 will be used,
if
On Tue, Apr 10, 2012 at 05:24:55PM +0200, Boszormenyi Zoltan wrote:
OK. Next question: now that both patches are intended to be applied,
should I send a unified single patch that contains the previous functionality
and the required fixes or a new one that only contains the last required
2012-04-10 17:34 keltezéssel, Michael Meskes írta:
On Tue, Apr 10, 2012 at 05:24:55PM +0200, Boszormenyi Zoltan wrote:
OK. Next question: now that both patches are intended to be applied,
should I send a unified single patch that contains the previous functionality
and the required fixes or a
Hi,
2012-04-10 16:55 keltezéssel, Michael Meskes írta:
On Tue, Apr 10, 2012 at 10:37:22AM -0400, Noah Misch wrote:
Only a non-decorated cursor can be overridden, even if
a different default readahead window size is specified with
e.g. ecpg -R 8. If ECPGFETCHSZ is not present, 8 will be used,
On Sat, Apr 07, 2012 at 11:50:42AM -0400, Noah Misch wrote:
Both. The second patch appeared after my first review, based on a comment in
that review. I looked at it during my re-review before marking the overall
project Ready for Committer.
Thanks.
I do call your attention to a question I
2012-04-08 16:25 keltezéssel, Michael Meskes írta:
On Sat, Apr 07, 2012 at 11:50:42AM -0400, Noah Misch wrote:
Both. The second patch appeared after my first review, based on a comment in
that review. I looked at it during my re-review before marking the overall
project Ready for Committer.
On Sun, Apr 08, 2012 at 06:35:33PM +0200, Boszormenyi Zoltan wrote:
Do you want me to change this or will you do it? I am on holiday
and will be back to work on wednesday.
I don't think waiting till later this week is a real problem.
The possibility to test different readahead window sizes
On Sun, Apr 08, 2012 at 04:25:01PM +0200, Michael Meskes wrote:
On Sat, Apr 07, 2012 at 11:50:42AM -0400, Noah Misch wrote:
I do call your attention to a question I raised in my second review: if a
program contains DECLARE foo READAHEAD 5 CURSOR FOR ... and the user runs
the program with
On Fri, Mar 30, 2012 at 12:48:07AM +0200, Boszormenyi Zoltan wrote:
Attached is the new core feature patch. Summary of changes:
...
I also refreshed the second patch that drives all cursors with the new
...
I'm slightly confused here. It seems Zoltan added a second patch *after* Noah
marked
On Sat, Apr 07, 2012 at 01:20:08PM +0200, Michael Meskes wrote:
On Fri, Mar 30, 2012 at 12:48:07AM +0200, Boszormenyi Zoltan wrote:
Attached is the new core feature patch. Summary of changes:
...
I also refreshed the second patch that drives all cursors with the new
...
I'm slightly
On Fri, Mar 30, 2012 at 12:48:07AM +0200, Boszormenyi Zoltan wrote:
2012-03-29 19:03 keltez?ssel, Noah Misch ?rta:
one of the new sections about readahead should somehow reference the hazard
around volatile functions.
Done.
I don't see the mention in your latest patch. You do mention it for
2012-03-29 12:59 keltezéssel, Boszormenyi Zoltan írta:
2012-03-29 02:43 keltezéssel, Noah Misch írta:
On Sat, Mar 24, 2012 at 10:49:07AM +0100, Boszormenyi Zoltan wrote:
+the window size may be modified by setting
theliteralECPGFETCHSZ/literal
+environment variable to a different
On Thu, Mar 29, 2012 at 12:59:40PM +0200, Boszormenyi Zoltan wrote:
2012-03-29 02:43 keltez?ssel, Noah Misch ?rta:
On Sat, Mar 24, 2012 at 10:49:07AM +0100, Boszormenyi Zoltan wrote:
+toliteralREADAHEAD number/literal. ExplicitliteralREADAHEAD
number/literal or
+literalNO
On Thu, Mar 29, 2012 at 01:03:41PM -0400, Noah Misch wrote:
Still, we're looking at dedicated ECPG syntax, quite visible even to folks
with no interest in Informix. We have eschewed littering our syntax with
compatibility aids, and I like it that way. IMO, an option to the ecpg
preprocessor
2012-03-29 20:34 keltezéssel, Michael Meskes írta:
On Thu, Mar 29, 2012 at 01:03:41PM -0400, Noah Misch wrote:
Still, we're looking at dedicated ECPG syntax, quite visible even to folks
with no interest in Informix. We have eschewed littering our syntax with
compatibility aids, and I like it
On Sat, Mar 24, 2012 at 10:49:07AM +0100, Boszormenyi Zoltan wrote:
Sorry for the delay, I had been busy with other tasks and I rewrote this code
to better cope with unknown result size, scrollable cursors and negative
cursor positions.
I think all points raised by Noah is addressed:
On Tue, Mar 6, 2012 at 6:06 AM, Noah Misch n...@leadboat.com wrote:
On Tue, Mar 06, 2012 at 07:07:41AM +0100, Boszormenyi Zoltan wrote:
2012-03-05 19:56 keltez?ssel, Noah Misch ?rta:
Or how about a new feature in the backend, so ECPG can do
UPDATE/DELETE ... WHERE OFFSET N OF cursor
On Tue, Mar 06, 2012 at 07:07:41AM +0100, Boszormenyi Zoltan wrote:
2012-03-05 19:56 keltez?ssel, Noah Misch ?rta:
Or how about a new feature in the backend, so ECPG can do
UPDATE/DELETE ... WHERE OFFSET N OF cursor
and the offset of computed from the actual cursor position and the
On Sun, Mar 04, 2012 at 05:34:50PM +0100, Boszormenyi Zoltan wrote:
The program logic shouldn't change at all. He meant that extra coding effort
is needed if you want manual caching. It requires 2 loops instead of 1 if you
use
FETCH N (N1).
Ah, thanks for the explanation.
Michael
--
On Sun, Mar 04, 2012 at 05:16:06PM +0100, Michael Meskes wrote:
On Fri, Mar 02, 2012 at 11:41:05AM -0500, Noah Misch wrote:
I suggest enabling the feature by default but drastically reducing the
default
readahead chunk size from 256 to, say, 5. That still reduces the FETCH
round
trip
On Sun, Mar 04, 2012 at 04:33:32PM +0100, Boszormenyi Zoltan wrote:
2012-03-02 17:41 keltez?ssel, Noah Misch ?rta:
On Thu, Dec 29, 2011 at 10:46:23AM +0100, Boszormenyi Zoltan wrote:
I suggest enabling the feature by default but drastically reducing the
default
readahead chunk size from
2012-03-05 19:56 keltezéssel, Noah Misch írta:
Having pondered the matter further, I now agree with Michael that the feature
should stay disabled by default. See my response to him for rationale.
Assuming that conclusion holds, we can recommended a higher value to users who
enable the
Hi,
first, thank you for answering and for the review.
2012-03-02 17:41 keltezéssel, Noah Misch írta:
On Thu, Dec 29, 2011 at 10:46:23AM +0100, Boszormenyi Zoltan wrote:
2011-11-16 20:51 keltez?ssel, Boszormenyi Zoltan ?rta:
2010-10-14 11:56 keltez?ssel, Boszormenyi Zoltan ?rta:
On Thu, Jun
On Fri, Mar 02, 2012 at 11:41:05AM -0500, Noah Misch wrote:
We yet lack a consensus on whether native ECPG apps should have access to the
feature. My 2c is to make it available, because it's useful syntactic sugar.
If your program independently processes each row of an arbitrary-length result
2012-03-04 17:16 keltezéssel, Michael Meskes írta:
On Fri, Mar 02, 2012 at 11:41:05AM -0500, Noah Misch wrote:
We yet lack a consensus on whether native ECPG apps should have access to the
feature. My 2c is to make it available, because it's useful syntactic sugar.
If your program
On Thu, Dec 29, 2011 at 10:46:23AM +0100, Boszormenyi Zoltan wrote:
2011-11-16 20:51 keltez?ssel, Boszormenyi Zoltan ?rta:
2010-10-14 11:56 keltez?ssel, Boszormenyi Zoltan ?rta:
On Thu, Jun 24, 2010 at 8:19 AM, Michael Meskes mes...@postgresql.org
wrote:
On Thu, Jun 24, 2010 at
On Thu, Jun 24, 2010 at 8:19 AM, Michael Meskes mes...@postgresql.org wrote:
On Thu, Jun 24, 2010 at 12:04:30PM +0300, Heikki Linnakangas wrote:
Is there a reason not to enable it by default? I'm a bit worried
that it will receive no testing if it's not always on.
Yes, there is a reason,
Hi,
Robert Haas írta:
On Thu, Jun 24, 2010 at 8:19 AM, Michael Meskes mes...@postgresql.org wrote:
On Thu, Jun 24, 2010 at 12:04:30PM +0300, Heikki Linnakangas wrote:
Is there a reason not to enable it by default? I'm a bit worried
that it will receive no testing if it's not always
Hi,
2010-06-23 22:42 keltezéssel, Bruce Momjian írta:
Boszormenyi Zoltan wrote:
Hi,
we improved ECPG quite a lot in 9.0 because we worked and
still working with an Informix to PostgreSQL migration project.
We came across a pretty big performance problem that can be seen in
every naive
On 24/06/10 10:27, Böszörményi Zoltán wrote:
And this readahead is not on by default, it's only activated
by ecpg -r fetch_readahead.
Is there a reason not to enable it by default? I'm a bit worried that it
will receive no testing if it's not always on.
--
Heikki Linnakangas
2010-06-24 11:04 keltezéssel, Heikki Linnakangas írta:
On 24/06/10 10:27, Böszörményi Zoltán wrote:
And this readahead is not on by default, it's only activated
by ecpg -r fetch_readahead.
Is there a reason not to enable it by default? I'm a bit worried that
it will receive no testing if
On Wed, Jun 23, 2010 at 04:42:37PM -0400, Bruce Momjian wrote:
I assume our ecpg version supports 1 fetch values, even in Informix
mode. Does it make sense to add lots of code to our ecpg then?
Yes, it does. The big question that zoltan and I haven't figured out yet, is
whether it makes sense
I think, yes, it does make sense. Because we are talking
about porting a whole lot of COBOL applications.
COBOL???
The ESQL/C or ECPG connector was already written
the Informix quirks in mind, so it fetches only one record
at a time passing it to the application. And similar performance
is
On Thu, Jun 24, 2010 at 12:04:30PM +0300, Heikki Linnakangas wrote:
Is there a reason not to enable it by default? I'm a bit worried
that it will receive no testing if it's not always on.
Yes, there is a reason, namely that you don't need it in native mode at all.
ECPG can read as many records
On Jun 24, 2010, at 2:13 PM, Michael Meskes wrote:
I think, yes, it does make sense. Because we are talking
about porting a whole lot of COBOL applications.
COBOL???
yes, COBOL :).
it is much more common than people think.
it is not the first COBOL request for PostgreSQL hitting my desk.
2010-06-24 14:13 keltezéssel, Michael Meskes írta:
I think, yes, it does make sense. Because we are talking
about porting a whole lot of COBOL applications.
COBOL???
Yes, OpenCOBOL...
The ESQL/C or ECPG connector was already written
the Informix quirks in mind, so it fetches only
Boszormenyi Zoltan wrote:
Hi,
we improved ECPG quite a lot in 9.0 because we worked and
still working with an Informix to PostgreSQL migration project.
We came across a pretty big performance problem that can be seen in
every naive application that uses only FETCH 1, FETCH RELATIVE
or
63 matches
Mail list logo
