@postgresql.org
Subject: Re: [PERFORM] query slows down drastically with increased
number of fields
"Tom Darci" <[EMAIL PROTECTED]> writes:
> It runs in about half a second (running in PgAdmin... the query run
> time, not the data retrieval time)
I don't have a lot of fa
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> On Thu, Oct 26, 2006 at 03:03:38PM -0700, George Pavlov wrote:
>> anyway, the funny thing is that if you concatenate
>> them the time drops:
> Sure. Take a look at the output and you'll see there's less data to
> shove around.
Even more to the point, p
On Thu, Oct 26, 2006 at 03:03:38PM -0700, George Pavlov wrote:
> i have wondered myself. i wouldn't do it through pgAdmin (not sure what
> the best test it, but i thought psql from the same machine might be
> better--see below). anyway, the funny thing is that if you concatenate
> them the time dro
ll
psql -dXXX -hYYY -UZZZ -o /dev/null 0.18s user 0.04s system 20% cpu
1.061 total
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Tom Darci
> Sent: Wednesday, October 25, 2006 10:21 AM
> To: pgsql-performance@postgresql.org
> Su
"Tom Darci" <[EMAIL PROTECTED]> writes:
> It runs in about half a second (running in PgAdmin... the query run
> time, not the data retrieval time)
I don't have a lot of faith in PgAdmin's ability to distinguish the two.
In fact, for a query such as you have here that's just a bare seqscan,
it's
Hello
All-
We have a
question about numbers of fields in the select clause of a query and how that
affects query speed.
The following
query simply selects the primary key field from a table with 100,000
records:
select p.
