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 201
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. W
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 re
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:
http://www.postgresql.org/mailp
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. https://github.com/zboszor/ecpg-readahead.gi
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. I was shocked by it initially, but on
further reading, I observed that
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
https://github.co
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 me
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 i
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 re
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 sa
> 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 s
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 rea
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 p
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 notice
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 curre
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 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
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
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
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,
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 ne
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
> fi
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 EC
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 b
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
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 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
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
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.
T
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
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 s
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
marke
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 m
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 th
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"
> preproce
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:
>>> +toREADAHEAD number. ExplicitREADAHEAD
>>> number or
>>> +NO READAHEAD turns cursor readahead on
>
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
theECPGFETCHSZ
+environment variable to a different value.
I had in min
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: per-
On Tue, Mar 6, 2012 at 6:06 AM, Noah Misch 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
>> >> and t
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
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 fe
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 s
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
> > roun
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 (N>1).
Ah, thanks for the explanation.
Michael
--
Mi
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 indep
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 resul
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
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
> >>> wrote:
> On Thu, Jun 24, 2010 at 12:04:30PM +030
Hi,
Robert Haas írta:
> On Thu, Jun 24, 2010 at 8:19 AM, Michael Meskes 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.
>>>
On Thu, Jun 24, 2010 at 8:19 AM, Michael Meskes 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, namely that you don
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 o
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
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
> 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
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 sens
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 it
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
Enterprise
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" a
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 RELATIV
63 matches
Mail list logo
