Skip site navigation (1) Skip section navigation (2)

Re: select slow?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Jaime Casanova" <el_vigia_ec(at)hotmail(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: select slow?
Date: 2004-03-31 15:40:21
Message-ID: 5090.1080747621@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-performance
"Jaime Casanova" <el_vigia_ec(at)hotmail(dot)com> writes:
> There are no indexes yet, and the table is just 6 rows long so even if 
> indexes exists the planner will do a seq scan. that's my whole point 63m for 
> seq scan in 6 rows table is too much.

That was 63 milliseconds, according to your original post, which seems
perfectly reasonable to me seeing that it's not a super-duper server.

The problem sounds to be either on the client side or somewhere in your
network.  I don't know anything about VB, but you might want to look
through the client-side operations to see what could be eating up the 13
seconds.

			regards, tom lane

In response to

Responses

pgsql-performance by date

Next:From: Chris KratzDate: 2004-03-31 15:42:48
Subject: Re: Delete performance on delete from table with inherited tables
Previous:From: Jaime CasanovaDate: 2004-03-31 14:27:50
Subject: Re: select slow?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group