Hi Rainer,
On Tue, Feb 05, 2008 at 10:24:11AM +1300, Rainer Spittel wrote:
> You are right, this query is not the right approach for performance
> testing. I thought that this will give an indication about the
> performance of a select statement on that table.
Only do benchmarking with real-wo
"Rainer Spittel" <[EMAIL PROTECTED]> writes:
> One of those slow queries are running on col02 which has a btree
> index. But I use the 'in' expression to get a set of matching rows:
> select * from table where col02 in ('...',[...],'...')
> This query gets sometimes really slow, I guess it d
Hi Tom,
You are right, this query is not the right approach for performance
testing. I thought that this will give an indication about the
performance of a select statement on that table.
One of those slow queries are running on col02 which has a btree
index. But I use the 'in' expression to
Hi Rainer,
On Tue, Feb 05, 2008 at 09:07:26AM +1300, Rainer Spittel wrote:
> When performing a 'select col01_id from table limit 1 offset 10;',
As Tom already stated, the result of this query is a bit random since
there is no ordering at all. What are you actually querying for?
Try tuning q
"Rainer Spittel" <[EMAIL PROTECTED]> writes:
> When performing a 'select col01_id from table limit 1 offset 10;',
> the query takes up to 20sec. Monitoring the dstats on the server, I see
> that the box is reading approx. 1GB from the disks.
No surprise. That query says "read 11 rows, the
Hi guys,
I am not really new to Postgres, but to be honest I am not an expert
on the internal configuration of Postgres. I run a couple of
PostgreSQL/PostGIS databases on several servers, but two of them are not
performing very well. Those two databases are just read-only databases
and they get
