"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
regards, tom lane
In response to
pgsql-performance by date
|Next:||From: Chris Kratz||Date: 2004-03-31 15:42:48|
|Subject: Re: Delete performance on delete from table with inherited tables|
|Previous:||From: Jaime Casanova||Date: 2004-03-31 14:27:50|
|Subject: Re: select slow?|