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

Re: select slow?

From: Paul Thomas <paul(at)tmsl(dot)demon(dot)co(dot)uk>
To: "pgsql-performance (at) postgresql (dot) org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: select slow?
Date: 2004-03-31 17:27:01
Message-ID: 20040331182701.A17746@bacon (view raw or flat)
Thread:
Lists: pgsql-performance
On 31/03/2004 16:40 Tom Lane wrote:
> "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.


Given that the client and server are on different machines, I'm wondering 
the bulk of the 13 seconds is due a network mis-configuration or a very 
slow DNS server...

-- 
Paul Thomas
+------------------------------+---------------------------------------------+
| Thomas Micro Systems Limited | Software Solutions for 
Business             |
| Computer Consultants         | 
http://www.thomas-micro-systems-ltd.co.uk   |
+------------------------------+---------------------------------------------+

In response to

pgsql-performance by date

Next:From: Gaetano MendolaDate: 2004-03-31 23:26:53
Subject: linux and anotime mount option
Previous:From: Michael GuerinDate: 2004-03-31 17:17:54
Subject: Estimated rows way off

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