I've noticed subsequent executions of the same insert command are slow.
I've searched the list archives for this matter and found several
entries
related, including suggestions how to speed up.
The standard answer from the core team is, use COPY.
Sorry, but this is from an application point of
Christoph Haller [EMAIL PROTECTED] writes:
Taken from the Reference Manual
[REPEATED] INSERT INTO ...
The key word REPEATED directs INGRES to encode the INSERT and save its
execution plan when it is first executed. This encoding can account for
significant performance improvements on
Hi all,
I was just wondering.The patches for making ecpg thread safe that were
floating around few days back, are they going to make in any near future
releases?
I am badly bitten by libpq as code i my multithreaded app. is growing
steadily. I find myself making stupid mistakes every now and
On Mon, 2003-02-24 at 07:22, Christoph Haller wrote:
I've noticed subsequent executions of the same insert command are slow.
I've searched the list archives for this matter and found several
entries
related, including suggestions how to speed up.
The standard answer from the core team is, use
On Sat, 22 Feb 2003, Peter Eisentraut wrote:
AFAICT, ILIKE cannot use an index. So why does ILIKE even exist, when
lower(expr) LIKE 'foo' provides a solution that can use an index and is
more standard, too?
I would guess because for lower(expr) to work you need to make an index on
it.
User's Guide section 7.2, example 7-1, claims that
SELECT 2 ^ 3 AS Exp;
will be equivalent, after type resolution, to
SELECT CAST(2 AS double precision) ^ CAST(3 AS double precision) AS Exp;
(which is true) or
SELECT 2.0 ^ 3.0 AS Exp;
which is not true, since 2.0 and 3.0 are nowadays of type
I need two answers I did not find in documentation :
How can I get exact number of rows in DECLARED CURSOR ?
OK, I can FETCH until NULL, but this does not fits my needs !
How can I get information is TRANSACTION already started ?
(TRANSACTION LEVEL)
The interface I'm using is libpq.
Peter Eisentraut [EMAIL PROTECTED] writes:
Josh Berkus writes:
4) It's just as indexible (or not indexable) as regexp comparisons, and easier
to understand for users from the Microsoft world than regexp.
ILIKE is not indexible at all.
You are arguing from a false premise.
regression=#
On Sunday 23 February 2003 20:52, Dave Page wrote:
-Original Message-
From: Ian Barwick [mailto:[EMAIL PROTECTED]
Would it be possible to modify the new docs to provide
similar functionality? E.g. something like
Tom Lane kirjutas E, 24.02.2003 kell 19:30:
Peter Eisentraut [EMAIL PROTECTED] writes:
Hey, I don't want to take your ILIKE away. But at the time it was added
the claim was that it was for compatibility and now we learn that that was
wrong.
This _is_ a compatibility feature, just not as
Josh Berkus writes:
4) It's just as indexible (or not indexable) as regexp comparisons, and easier
to understand for users from the Microsoft world than regexp.
ILIKE is not indexible at all. Other forms of pattern comparisons are at
least indexible sometimes.
--
Peter Eisentraut [EMAIL
Peter,
4) It's just as indexible (or not indexable) as regexp comparisons, and
easier to understand for users from the Microsoft world than regexp.
ILIKE is not indexible at all. Other forms of pattern comparisons are at
least indexible sometimes.
And how is ~* indexable?
--
Josh
On Mon, 17 Feb 2003 09:51:54 +0800, Christopher Kings-Lynne
[EMAIL PROTECTED] wrote:
Strategy three:
begin;
lock table in exclusive mode;
update row;
if (no rows affected) insert row;
commit;
Problem - Works, but this table needs high concurrency.
Chris,
distributing congestion might improve
On Sun, 2003-02-23 at 23:31, Tom Lane wrote:
Josh Berkus [EMAIL PROTECTED] writes:
- Some other databases support ILIKE and it makes porting easier.
Which other ones? I checked our archives and found that when we were
discussing adding ILIKE, it was claimed that Oracle had it. But I can't
Tom Lane writes:
My feeling too. Whatever you may think of its usefulness, it's been a
documented feature since 7.1. It's a bit late to reconsider.
It's never too late for new users to reconsider. It's also never too late
to change your application of performance is not satisfactory.
--
Josh Berkus writes:
- Some other databases support ILIKE and it makes porting easier.
Which database would that be?
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
On Mon, 24 Feb 2003, Peter Eisentraut wrote:
Tom Lane writes:
My feeling too. Whatever you may think of its usefulness, it's been a
documented feature since 7.1. It's a bit late to reconsider.
It's never too late for new users to reconsider. It's also never too late
to change your
Peter Eisentraut wrote:
Tom Lane writes:
My feeling too. Whatever you may think of its usefulness, it's been a
documented feature since 7.1. It's a bit late to reconsider.
It's never too late for new users to reconsider. It's also never too late
to change your application of performance is not
On Tue, 25 Feb 2003, Justin Clift wrote:
Peter Eisentraut wrote:
Tom Lane writes:
My feeling too. Whatever you may think of its usefulness, it's been a
documented feature since 7.1. It's a bit late to reconsider.
It's never too late for new users to reconsider. It's also never too
Vince Vielhaber [EMAIL PROTECTED] writes:
On Tue, 25 Feb 2003, Justin Clift wrote:
As an alternative to _removing_ it, would a feasible idea be to
transparently alias it to something else, say a specific type of regex
query or something?
Why screw with it for the sake of screwing with it?
Vince Vielhaber writes:
It's never too late for new users to reconsider. It's also never too late
to change your application of performance is not satisfactory.
And if performance is satisfactory?
Hey, I don't want to take your ILIKE away. But at the time it was added
the claim was that
Peter Eisentraut [EMAIL PROTECTED] writes:
Hey, I don't want to take your ILIKE away. But at the time it was added
the claim was that it was for compatibility and now we learn that that was
wrong. That is something to make people aware of, for example in the
documentation.
It already does
Given that the direction of the spec seems to be headed towards the
desired syntax, can we put this on the TODO list?
Dave
On Thu, 2003-02-20 at 11:49, Dave Cramer wrote:
Scott,
I can't find page 858 in that document, is it the right one?
also the link s/b ?
Four Reasons to use ILIKE, which have nothing to do with mSQL:
1) It's faster to type than most analagous regexp comparisons, and much faster
than comparing two LOWERs or two UPPERS.
2) It's a great operator for comparing two text variables or columns of small
tables where you don't want to
On Mon, Feb 24, 2003 at 07:53:05PM +, Darko Prenosil wrote:
I need two answers I did not find in documentation :
How can I get exact number of rows in DECLARED CURSOR ?
OK, I can FETCH until NULL, but this does not fits my needs !
You need to move to the end of the cursor. When you
After failing to make Itanium competitive, Intel is now downplaying
64-bit CPU's. Of course, they didn't think that until Itanium failed.
Here is the slashdot story:
http://slashdot.org/article.pl?sid=03/02/23/2050237mode=nestedtid=118
Seems AMD's hammer is going to be the popular
26 matches
Mail list logo
