> --- Original Message ---
> From: Peter <[EMAIL PROTECTED]>
> To: pgsql-general@postgresql.org
> Sent: 03/02/07, 10:58:08
> Subject: Re: [GENERAL] Query optimization problem
>
> >>> Try SELECT count(*) FROM ... instead and see if the times are clos
Try SELECT count(*) FROM ... instead and see if the times are closer.
Correct. That executes in 300ms flat:
So your problem is data transfer, not the query per se.
Well, based on PgAdmin times I suspected some sort of heavy 'data
preparation before it's sent out' overhead
How old a pgAdm
Peter <[EMAIL PROTECTED]> writes:
>> Try SELECT count(*) FROM ... instead and see if the times are closer.
> Correct. That executes in 300ms flat:
So your problem is data transfer, not the query per se.
How old a pgAdmin are you using?
regards, tom lane
>> I'm not sure if I'm heading up the right alley - seems too simple!,
but here is my issue.
>>
>> I have about 3000 records in 'mytable', and simple
>
>Number of rows is not the most important thing here - the number of
>occupied disc pages is (you can have a lot of small rows or a small
>nub
Query returned successfully with no result in 600 ms.
Why SELECT takes 3+ second to execute? Is it something to do with my
Postgres server optimization, or PgAdmin does not show correct data
retrieval runtime (leaks over into query runtime or something)?
Data transfer and display time usually
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/02/07 07:22, Richard Huxton wrote:
> Peter wrote:
>>
>> Query returned successfully with no result in 600 ms.
>>
>> Why SELECT takes 3+ second to execute? Is it something to do with my
>> Postgres server optimization, or PgAdmin does not show cor
Richard Huxton wrote:
Peter wrote:
Query returned successfully with no result in 600 ms.
Why SELECT takes 3+ second to execute? Is it something to do with my
Postgres server optimization, or PgAdmin does not show correct data
retrieval runtime (leaks over into query runtime or something)?
Peter wrote:
Query returned successfully with no result in 600 ms.
Why SELECT takes 3+ second to execute? Is it something to do with my
Postgres server optimization, or PgAdmin does not show correct data
retrieval runtime (leaks over into query runtime or something)?
Data transfer and displ
I'm not sure if I'm heading up the right alley - seems too simple!, but
here is my issue.
I have about 3000 records in 'mytable', and simple
select * from mytable where x=1
is timed as:
Total query runtime: 2933 ms.
Data retrieval runtime: 791 ms.
EXPLAIN says it's Seq Scan, but the actual f
