On 16.06.2005 16:00 Scott Marlowe wrote:
There's got to be more happening than what this is showing us. A
select, and looping through it, should involve no writes, and therefore
no real performance difference from autocommit versus not. Is there
some underlying trigger on the view or
On 16.06.2005 17:29 PFC wrote:
If autocommit is on (or fetch size is zero) then the driver will
build the whole
result set before returning to the caller.
Sure, but that is not your problem : even building the whole result
set should not take longer than a few seconds (I gave you
PFC wrote on 14.06.2005 14:26:
[...]
Now I fire up python, do a SELECT * from the table and retrieve all
the data as native objects... Hm, it takes about 1.3 seconds... on my
Pentium-M 1600 laptop...
Don't you have a problem somewhere ? Are you sure it's not swapping
? did you
PFC wrote on 15.06.2005 22:04:
It's not the program or Java. The same program takes about 20 seconds
with Firebird and the exactly same data.
Hm, that's still very slow (it should do it in a couple seconds like
my PC does... maybe the problem is common to postgres and firebird ?)
On 09.06.2005 03:13 Alain wrote:
Tom Lane escreveu:
Thomas Kellerer [EMAIL PROTECTED] writes:
Is there anything I can do, to convince PG to return the first row
more quickly?
Are you now looking for the LIMIT ?
SELECT * FROM table LIMIT 1;
and when when you wnat the rest
On 09.06.2005 02:06 Tom Lane wrote:
Thomas Kellerer [EMAIL PROTECTED] writes:
Is there anything I can do, to convince PG to return the first row more
quickly?
The solution is to use a cursor and FETCH a reasonably small number of
rows at a time.
Thanks for all your answers.
I turned out
Hello,
I have a table with roughly 100,000 rows (four varchar(100) columns). This
is basically test data I generated for something else. I'm using JDBC to
access PG (but the behaviour is the same with psql).
The problem is, that a SELECT * FROM foobar; takes ages (roughly 3 minutes)
to
On 19.04.2005 11:48 Muhammad Nadeem Ashraf wrote:
Hi,
I am new user of PostGreSQL 8.0.1. While using it i faced following
issue. As SQL is Case insensetive Language So the Uper or Lower cases
are not significant. But while using the database there is problem.
If i Create new Table with
101 - 108 of 108 matches
Mail list logo