On Wed, 2005-06-15 at 17:08, Thomas Kellerer wrote:
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
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
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 test timings in a
previous
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
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 ?)
Try eliminating disk IO by writing a
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 ?)
The problem is, that a SELECT * FROM foobar; takes ages (roughly 3
minutes) to return the first row. I played around with the fetchSize()
to disable the result set caching in the Java program first (before I
tried psql) but that did not change anything.
Hello,
Yours seemed
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 of
Hi,
On 6/9/05, Thomas Kellerer [EMAIL PROTECTED] wrote:
No I want the whole result.
As Tom underlined:
On 6/9/05, Tom Lane [EMAIL PROTECTED] wrote:
The solution is to use a cursor and FETCH a reasonably
small number of rows at a time.
AFAIC, query results are stored as arrays in PGresult
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
Thomas Kellerer [EMAIL PROTECTED] writes:
Is there anything I can do, to convince PG to return the first row more
quickly?
libpq's API for PQresult is such that it really doesn't have any choice
but to collect the full result set before it hands you back the
PQresult. I don't know JDBC very
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 of it:
SELECT * FROM table OFFSET 1;
Alain
David Olbersen wrote:
On Sun, 18 Mar 2001, Fernando Eduardo B. L. e Carvalho wrote:
select p.city,count(*) from sales s, person p where s.doc = p.doc
group by p.city;
Anyone help-me?
1: VACUUM ANALYZE sales
VACUUM ANALYZE person;
2: That 'count(*)' is going to be
Table 1
create table person (
doc text primary key,
etc
city text );
9 rows
create table sales (
doc text,
etc .
);
30 rows
select
16 matches
Mail list logo
