pg.ddx.io pgsql-sql@postgresql.org mailing list archive
help / color / mirror / Atom feedSelect very slow...
19+ messages / 10 participants
[nested] [flat]
* Select very slow...
@ 2001-03-18 09:15 Fernando Eduardo B. L. e Carvalho <feblec@ig.com.br>
0 siblings, 1 reply; 19+ messages in thread
From: Fernando Eduardo B. L. e Carvalho @ 2001-03-18 09:15 UTC (permalink / raw)
To: pgsql-sql
Table 1
create table person (
doc text primary key,
etc ....
city text );
90000 rows
create table sales (
doc text,
etc .....
);
300000 rows
select p.city,count(*) from sales s, person p where s.doc = p.doc
group by p.city;
Anyone help-me?
^ permalink raw reply [nested|flat] 19+ messages in thread
* Re: Select very slow...
@ 2001-03-18 18:42 David Olbersen <dave@slickness.org>
parent: Fernando Eduardo B. L. e Carvalho <feblec@ig.com.br>
0 siblings, 1 reply; 19+ messages in thread
From: David Olbersen @ 2001-03-18 18:42 UTC (permalink / raw)
To: Fernando Eduardo B. L. e Carvalho <feblec@ig.com.br>; +Cc: pgsql-sql
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's indexed (p.doc might work?)
3: EXPLAIN <your select from above>;
That should give you some hints on what to optimize.
-- Dave
^ permalink raw reply [nested|flat] 19+ messages in thread
* Re: Select very slow...
@ 2001-03-19 23:54 Joseph Shraibman <jks@selectacast.net>
parent: David Olbersen <dave@slickness.org>
0 siblings, 0 replies; 19+ messages in thread
From: Joseph Shraibman @ 2001-03-19 23:54 UTC (permalink / raw)
To: David Olbersen <dave@slickness.org>; +Cc: Fernando Eduardo B. L. e Carvalho <feblec@ig.com.br>; pgsql-sql
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 slow.
> Try counting a column that's indexed (p.doc might work?)
>
I don't think that is true.
--
Joseph Shraibman
jks@selectacast.net
Increase signal to noise ratio. http://www.targabot.com
^ permalink raw reply [nested|flat] 19+ messages in thread
* Re: Select very slow
@ 2001-03-20 08:59 Mark Kirkwood <markir@i4free.co.nz>
0 siblings, 0 replies; 19+ messages in thread
From: Mark Kirkwood @ 2001-03-20 08:59 UTC (permalink / raw)
To: dave@slickness.org; feblec@ig.com.br; jks@selectacast.netT; +Cc: pgsql-sql
>
> That 'count(*)' is going to be slow.
> Try counting a column that's indexed (p.doc might work?)
That is not the case, you can convince yourself with explain - you get the
same plan(s) :
e.g : ( table dim0 with indexed column d0key ) ...
explain select count(*) from dim0 where d0key < 1000;
Aggregate (cost=96.13..96.13 rows=1 width=0)
-> Index Scan using dim0_pk on dim0 (cost=0.00..93.63 rows=1000 width=0)
explain select count(d0key) from dim0 where d0key < 1000;
Aggregate (cost=96.13..96.13 rows=1 width=4)
-> Index Scan using dim0_pk on dim0 (cost=0.00..93.63 rows=1000 width=4)
> (the tables and query snipped..).
> anyone help-me ?
>
I would try to make the primary key ( doc) a fixed length varchar(n) instead
of text if possible, as text is intended for very long strings and btree
indexes usually perform best on (small) fixed length columns.
If your key is going to be a really long string then maybe rethink the design
( use a "synthetic" key like a sequence or integer checksum of doc to index
on ).
perform a vacuum analyze and then post the output of the explain below to
this list !
explain select p.city,count(*) from sales s, person p where s.doc = p.doc
group by p.city;
Cheers
Mark
^ permalink raw reply [nested|flat] 19+ messages in thread
* SELECT very slow
@ 2005-06-08 21:46 Thomas Kellerer <spam_eater@gmx.net>
0 siblings, 2 replies; 19+ messages in thread
From: Thomas Kellerer @ 2005-06-08 21:46 UTC (permalink / raw)
To: pgsql-sql
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 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.
It seems that PG is actually building up the full result set in the
background before delivering the first row. But I cannot see any of the
processes (neither my Java process nor the PG processes) using a lot of
memory - which I would expect if a result set of that size is created.
I need to test a program which should process large result sets (without
loading it into memory) and waiting nearly three minutes before it actually
starts working is a bit annoying :)
A SELECT count(*) FROM foobar is quite fast (about 2 seconds)
I hate to say this, but the same SELECT returns the first row more or less
instantly with Firebird, SQL Server (MSDE) and HSQLDB.
Is there anything I can do, to convince PG to return the first row more
quickly?
I tried a VACUUM FULL, no change. I increased the shared_buffers to 1000,
no improvement either.
The execution plan is not really surprising:
Seq Scan on foobar (cost=0.00..2510.04 rows=117504 width=63)
I'm using PG 8.0.3 on Win2K.
Thanks in advance
Thomas
^ permalink raw reply [nested|flat] 19+ messages in thread
* Re: SELECT very slow
@ 2005-06-09 00:06 Tom Lane <tgl@sss.pgh.pa.us>
parent: Thomas Kellerer <spam_eater@gmx.net>
1 sibling, 3 replies; 19+ messages in thread
From: Tom Lane @ 2005-06-09 00:06 UTC (permalink / raw)
To: Thomas Kellerer <spam_eater@gmx.net>; +Cc: pgsql-sql
Thomas Kellerer <spam_eater@gmx.net> 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 well but I think it has similar
semantic constraints.
The solution is to use a cursor and FETCH a reasonably small number of
rows at a time.
regards, tom lane
^ permalink raw reply [nested|flat] 19+ messages in thread
* Re: SELECT very slow
@ 2005-06-09 01:13 Alain <alainm@pobox.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
2 siblings, 1 reply; 19+ messages in thread
From: Alain @ 2005-06-09 01:13 UTC (permalink / raw)
To: pgsql-sql
Tom Lane escreveu:
> Thomas Kellerer <spam_eater@gmx.net> 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
^ permalink raw reply [nested|flat] 19+ messages in thread
* Re: SELECT very slow
@ 2005-06-09 06:56 Thomas Kellerer <spam_eater@gmx.net>
parent: Alain <alainm@pobox.com>
0 siblings, 1 reply; 19+ messages in thread
From: Thomas Kellerer @ 2005-06-09 06:56 UTC (permalink / raw)
To: pgsql-sql
On 09.06.2005 03:13 Alain wrote:
>
>
> Tom Lane escreveu:
>
>> Thomas Kellerer <spam_eater@gmx.net> 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;
>
No I want the whole result.
Thomas
^ permalink raw reply [nested|flat] 19+ messages in thread
* Re: SELECT very slow
@ 2005-06-09 06:58 Thomas Kellerer <spam_eater@gmx.net>
parent: Tom Lane <tgl@sss.pgh.pa.us>
2 siblings, 0 replies; 19+ messages in thread
From: Thomas Kellerer @ 2005-06-09 06:58 UTC (permalink / raw)
To: pgsql-sql
On 09.06.2005 02:06 Tom Lane wrote:
> Thomas Kellerer <spam_eater@gmx.net> 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 well but I think it has similar
> semantic constraints.
>
> The solution is to use a cursor and FETCH a reasonably small number of
> rows at a time.
>
My understanding was that setting the fetchSize() to 1 in JDBC would force the
use of a cursor.
I'll have to go through the JDBC docs again to check how I can enforce this.
Thanks for the answer though
Thomas
^ permalink raw reply [nested|flat] 19+ messages in thread
* Re: SELECT very slow
@ 2005-06-09 07:31 Volkan YAZICI <volkan.yazici@gmail.com>
parent: Thomas Kellerer <spam_eater@gmx.net>
0 siblings, 0 replies; 19+ messages in thread
From: Volkan YAZICI @ 2005-06-09 07:31 UTC (permalink / raw)
To: Thomas Kellerer <spam_eater@gmx.net>; +Cc: pgsql-sql
Hi,
On 6/9/05, Thomas Kellerer <spam_eater@gmx.net> wrote:
> No I want the whole result.
As Tom underlined:
On 6/9/05, Tom Lane <tgl@sss.pgh.pa.us> 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 structures.
Thus, storing huge result sets in a single struct is not very
feasible; although, you can face with theoretical limits like MAX_INT
in the long run. Moreover, it's so rare to see any practical use of
retrieving thousands of rows. If you're getting quite huge sets of
data, you should try grouping them with suitable statements.
IMHO, you should use cursors to fetch a suitable amount of row from
related table and forward it recursively. (Furthermore, I think this
is one of the design goals of FETCH mechanism.)
Although, as I see from most API implementations (like C++, Perl, PHP,
Python and etc.), they use libpq as layer between API and server.
Therefore, you'll probably encounter with every limitation of libpq
with other programming languages out of C too.
Regards.
^ permalink raw reply [nested|flat] 19+ messages in thread
* Re: SELECT very slow
@ 2005-06-09 11:30 Thomas Kellerer <spam_eater@gmx.net>
parent: Tom Lane <tgl@sss.pgh.pa.us>
2 siblings, 0 replies; 19+ messages in thread
From: Thomas Kellerer @ 2005-06-09 11:30 UTC (permalink / raw)
To: pgsql-sql
On 09.06.2005 02:06 Tom Lane wrote:
> Thomas Kellerer <spam_eater@gmx.net> 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 that I did not read the JDBC documentation closely enough (blush)
Setting the fetchSize to 1 (or something >0) only uses a cursor if autocommit is
disabled (due to the annoying "transaction is aborted" when running DDL scripts
that have errors, I usually turn autocommit on).
With autocommit off, the rows will be returned "immediately" (so the driver is
using a cursor to fetch the data)
Regards
Thomas
^ permalink raw reply [nested|flat] 19+ messages in thread
* Re: SELECT very slow
@ 2005-06-14 12:26 PFC <lists@boutiquenumerique.com>
parent: Thomas Kellerer <spam_eater@gmx.net>
1 sibling, 2 replies; 19+ messages in thread
From: PFC @ 2005-06-14 12:26 UTC (permalink / raw)
To: Thomas Kellerer <spam_eater@gmx.net>; pgsql-sql
> 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 strange so I tried this :
Created a table with 128K lines, 4 TEXT columns containing about 70 chars
each...
---------------------------------------------
\d bigtest;
Colonne | Type | Modificateurs
---------+---------+---------------------------------------------------------
id | integer | not null default
nextval('public.bigtest_id_seq'::text)
data1 | text |
data2 | text |
data3 | text |
data4 | text |
Index :
«bigtest_pkey» PRIMARY KEY, btree (id)
---------------------------------------------
SELECT count(*) from bigtest;
count
--------
131072
---------------------------------------------
explain analyze select * from bigtest;
QUERY PLAN
------------------------------------------------------------------------------------------------------------------
Seq Scan on bigtest (cost=0.00..7001.72 rows=131072 width=308) (actual
time=0.035..484.249 rows=131072 loops=1)
Total runtime: 875.095 ms
So grabbing the data takes 0.875 seconds.
---------------------------------------------
SELECT avg(length(data1)),
avg(length(data2)),avg(length(data3)),avg(length(data3)) from bigtest;
avg | avg | avg |
avg
---------------------+---------------------+---------------------+---------------------
72.1629180908203125 | 72.2342376708984375 | 72.3680572509765625 |
72.3680572509765625
Here you see the average data sizes.
---------------------------------------------
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...
I was about to suggest you use a less slow and bloated language than
Java, but then on my machine psql takes about 5 seconds to display the
results, so it looks like it ain't Java. psql is slow because it has to
format the result and compute the column widths.
Don't you have a problem somewhere ? Are you sure it's not swapping ? did
you check memory ? Are you transferring all this data over the network ?
Might an obscure cabling problem have reverted your connection to 10 Mbps ?
I'm using pg 8.0.something on Linux.
Ouch. I saw you're on Windows so I tried it on the windows machine there
which has a postgres installed, over a 100Mbps network, querying from my
linux laptop. The windows machine is a piece of crap, Pentium-II 300 and
256 MB Ram, it takes 7 seconds to retrieve the whole table in a python
native object.
So...
^ permalink raw reply [nested|flat] 19+ messages in thread
* Re: SELECT very slow
@ 2005-06-15 18:05 Thomas Kellerer <spam_eater@gmx.net>
parent: PFC <lists@boutiquenumerique.com>
1 sibling, 1 reply; 19+ messages in thread
From: Thomas Kellerer @ 2005-06-15 18:05 UTC (permalink / raw)
To: pgsql-sql
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 check memory ? Are you transferring all this data over the
> network ? Might an obscure cabling problem have reverted your
> connection to 10 Mbps ?
I'm sure. Everything is running on the same machine, about 350 MB free memory.
> Ouch. I saw you're on Windows so I tried it on the windows machine
> there which has a postgres installed, over a 100Mbps network, querying
> from my linux laptop. The windows machine is a piece of crap,
> Pentium-II 300 and 256 MB Ram, it takes 7 seconds to retrieve the whole
> table in a python native object.
>
It's not the program or Java. The same program takes about 20 seconds with
Firebird and the exactly same data.
Thomas
^ permalink raw reply [nested|flat] 19+ messages in thread
* Re: SELECT very slow
@ 2005-06-15 20:04 PFC <lists@boutiquenumerique.com>
parent: PFC <lists@boutiquenumerique.com>
1 sibling, 1 reply; 19+ messages in thread
From: PFC @ 2005-06-15 20:04 UTC (permalink / raw)
To: Thomas Kellerer <spam_eater@gmx.net>; pgsql-sql
> 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 set returning function which returns
1000000 rows, something simple like just a sequence number and a text
value... if this is slow too... i don't know... do you have an antivirus
or zonealarm or something ?
Have you tried connecting from another machine ?
>
> Thomas
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>
^ permalink raw reply [nested|flat] 19+ messages in thread
* Re: SELECT very slow
@ 2005-06-15 22:08 Thomas Kellerer <spam_eater@gmx.net>
parent: PFC <lists@boutiquenumerique.com>
0 siblings, 1 reply; 19+ messages in thread
From: Thomas Kellerer @ 2005-06-15 22:08 UTC (permalink / raw)
To: pgsql-sql
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 ?)
>
> Try eliminating disk IO by writing a set returning function which
> returns 1000000 rows, something simple like just a sequence number and
> a text value... if this is slow too... i don't know...
> do you have an antivirus or zonealarm or something ?
Wouldn't that affect all DB access not only PG? And as I said, all other
The 20 seconds are ok. This includes processing of the data in the
application. If I simply loop over the result set and get each column's
value without further processing it takes 4 seconds with Firebird.
Basically I'm doing the following:
rs = stmt.executeQuery("select * from foo");
while (rs.next())
{
for (int i=0; i < 4; i++)
{
Object o = rs.getObject(i+1);
}
}
As I said in my other post, the behaviour/performance in PG is dependent on
the autocommit setting for the connection.
With autocommit set to false the above code takes about 3 seconds in PG
but wit autocommit set to true, PG takes 3 minutes! It seems that it also
is very dependent on the fetchsize (apparently the number of rows that are
cached by the driver). Anything above 100 seems to slow down the overall
process.
Regards
Thomas
^ permalink raw reply [nested|flat] 19+ messages in thread
* Re: SELECT very slow
@ 2005-06-16 14:00 Scott Marlowe <smarlowe@g2switchworks.com>
parent: Thomas Kellerer <spam_eater@gmx.net>
0 siblings, 1 reply; 19+ messages in thread
From: Scott Marlowe @ 2005-06-16 14:00 UTC (permalink / raw)
To: Thomas Kellerer <spam_eater@gmx.net>; +Cc: pgsql-sql
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 does... maybe the problem is common to postgres and firebird ?)
> >
> > Try eliminating disk IO by writing a set returning function which
> > returns 1000000 rows, something simple like just a sequence number and
> > a text value... if this is slow too... i don't know...
>
> > do you have an antivirus or zonealarm or something ?
> Wouldn't that affect all DB access not only PG? And as I said, all other
>
> The 20 seconds are ok. This includes processing of the data in the
> application. If I simply loop over the result set and get each column's
> value without further processing it takes 4 seconds with Firebird.
>
> Basically I'm doing the following:
>
> rs = stmt.executeQuery("select * from foo");
> while (rs.next())
> {
> for (int i=0; i < 4; i++)
> {
> Object o = rs.getObject(i+1);
> }
> }
>
> As I said in my other post, the behaviour/performance in PG is dependent on
> the autocommit setting for the connection.
>
> With autocommit set to false the above code takes about 3 seconds in PG
> but wit autocommit set to true, PG takes 3 minutes! It seems that it also
> is very dependent on the fetchsize (apparently the number of rows that are
> cached by the driver). Anything above 100 seems to slow down the overall
> process.
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 something like that? Some kind
of auditing function?
^ permalink raw reply [nested|flat] 19+ messages in thread
* Re: SELECT very slow
@ 2005-06-16 14:45 Thomas Kellerer <spam_eater@gmx.net>
parent: Scott Marlowe <smarlowe@g2switchworks.com>
0 siblings, 0 replies; 19+ messages in thread
From: Thomas Kellerer @ 2005-06-16 14:45 UTC (permalink / raw)
To: pgsql-sql
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 something like that? Some kind
> of auditing function?
That's exactly the code that produced the mentioned timings. This is - according
to the JDBC driver's documentation - the expected behaviour. The driver can be
set to use cursor based fetching but *only* if autocommit is false.
If autocommit is on (or fetch size is zero) then the driver will build the whole
result set before returning to the caller.
http://jdbc.postgresql.org/documentation/80/query.html#query-with-cursor
Thomas
^ permalink raw reply [nested|flat] 19+ messages in thread
* Re: SELECT very slow
@ 2005-06-16 15:29 PFC <lists@boutiquenumerique.com>
parent: Thomas Kellerer <spam_eater@gmx.net>
0 siblings, 1 reply; 19+ messages in thread
From: PFC @ 2005-06-16 15:29 UTC (permalink / raw)
To: Thomas Kellerer <spam_eater@gmx.net>; pgsql-sql
> 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).
So... what ?
What does the taskman say ? CPU at 100% ? how much kernel time ?
>
> http://jdbc.postgresql.org/documentation/80/query.html#query-with-cursor
>
> Thomas
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
>
^ permalink raw reply [nested|flat] 19+ messages in thread
* Re: SELECT very slow
@ 2005-06-16 15:33 Thomas Kellerer <spam_eater@gmx.net>
parent: PFC <lists@boutiquenumerique.com>
0 siblings, 0 replies; 19+ messages in thread
From: Thomas Kellerer @ 2005-06-16 15:33 UTC (permalink / raw)
To: pgsql-sql
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 test timings
> in a previous message).
> So... what ?
> What does the taskman say ? CPU at 100% ? how much kernel time ?
>
Taskmanager (I'm on windows) does not show any high CPU usage. And (as I wrote
in the initial post) I cannot see any memory increase in the PG process as well
(which I would expect with a result set of that size built up in memory).
Thomas
^ permalink raw reply [nested|flat] 19+ messages in thread
end of thread, other threads:[~2005-06-16 15:33 UTC | newest]
Thread overview: 19+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2001-03-18 09:15 Select very slow... Fernando Eduardo B. L. e Carvalho <feblec@ig.com.br>
2001-03-18 18:42 ` David Olbersen <dave@slickness.org>
2001-03-19 23:54 ` Joseph Shraibman <jks@selectacast.net>
2001-03-20 08:59 Re: Select very slow Mark Kirkwood <markir@i4free.co.nz>
2005-06-08 21:46 SELECT very slow Thomas Kellerer <spam_eater@gmx.net>
2005-06-09 00:06 ` Re: SELECT very slow Tom Lane <tgl@sss.pgh.pa.us>
2005-06-09 01:13 ` Re: SELECT very slow Alain <alainm@pobox.com>
2005-06-09 06:56 ` Re: SELECT very slow Thomas Kellerer <spam_eater@gmx.net>
2005-06-09 07:31 ` Re: SELECT very slow Volkan YAZICI <volkan.yazici@gmail.com>
2005-06-09 06:58 ` Re: SELECT very slow Thomas Kellerer <spam_eater@gmx.net>
2005-06-09 11:30 ` Re: SELECT very slow Thomas Kellerer <spam_eater@gmx.net>
2005-06-14 12:26 ` Re: SELECT very slow PFC <lists@boutiquenumerique.com>
2005-06-15 18:05 ` Re: SELECT very slow Thomas Kellerer <spam_eater@gmx.net>
2005-06-16 15:29 ` Re: SELECT very slow PFC <lists@boutiquenumerique.com>
2005-06-16 15:33 ` Re: SELECT very slow Thomas Kellerer <spam_eater@gmx.net>
2005-06-15 20:04 ` Re: SELECT very slow PFC <lists@boutiquenumerique.com>
2005-06-15 22:08 ` Re: SELECT very slow Thomas Kellerer <spam_eater@gmx.net>
2005-06-16 14:00 ` Re: SELECT very slow Scott Marlowe <smarlowe@g2switchworks.com>
2005-06-16 14:45 ` Re: SELECT very slow Thomas Kellerer <spam_eater@gmx.net>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox