how about normalizing the schema for start ?
by the looks of it, you have huge table,with plenty of varchars, that
smells like bad design of db.
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
The few 'obvious' things I see :
ID and POLLID aren't of the same type (numeric vs bigint)
TTIME isn't indexed.
And as a general matter, you should stick to native datatypes if you don't
need numeric.
But as said in the other answer, maybe you should redo this schema and use
more consistent
Dear All,
We are using Postgres 8.3.7 in our java application. We are doing performances
tuning and load testing in our setup. we have noticed that ,some of our queries
to the database taking long time to return the results.Please find our setup
details belows.
We observed that postgres
Dear All,
We are
using Postgres 8.3.7 in our java application. We are doing performances
tuning and load testing in our setup. we have noticed that ,some of our
queries to the database taking long time to return the results.Please
find our setup details belows.
We observed that postgres is
,some of our queries to the database taking long time to return the
results.
fsync: off (even we tested this parameter is on ,we observed the same
slowness )
If your queries take long time to return results, I suppose you are
talking about SELECTs.
fsync = off will not make
parimala escreveu:
[Don't repeat your answer. It's a PITA to receive multiple identical copies]
We are using Postgres 8.3.7 in our java application. We are doing
performances tuning and load testing in our setup. we have noticed that
,some of our queries to the database taking long time to
