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 g
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 message).
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 som
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 l
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 ?)
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 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 ch
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 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
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?
>
>
> libpq's API for PQresult is such that it really doesn't have any choice
> but to collect the full result set before it
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 PGres
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
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
--
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 ver
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 retur
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 g
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 slow.
Try counting a column that'
Table 1
create table person (
doc text primary key,
etc
city text );
9 rows
create table sales (
doc text,
etc .
);
30 rows
select p.city,coun
18 matches
Mail list logo
