On 13-Jan-07, at 7:24 PM, Tom Lane wrote:
Jignesh Shah <[EMAIL PROTECTED]> writes:
The appserver is basically using bunch of prepared statements that
the
server should be executing directly without doing the parsing again.
Better have another look at that theory, because you're clearly
s
Have you run vacuum and analyze on the table? What version of Postgres are
you running? What OS are you using?
This looks like a straight forward query. With any database the first time
you run the query its going to be slower because it actually has to read off
disk. The second time its fast
Jignesh Shah <[EMAIL PROTECTED]> writes:
> The appserver is basically using bunch of prepared statements that the
> server should be executing directly without doing the parsing again.
Better have another look at that theory, because you're clearly spending
a lot of time in parsing (operator res
Hello All,
I am using the latest 8.2 source that I compiled with Sun Studio 11 and
tested it on Solaris 10 11/06 against an app server. I find that the CPU
utilization was higher than I expected and started digging through it.
Aparently the top CPU usage comes from the following stack trace w
What if we start a project where we define tests for PostgreSQL
overall performance and individual points with any database structure?
It could be done, throught a SQL logger and statistics, where we can
see complete processess and measure then after. We have many things to
measure, and something
Hello
I am going to separate physical locations of tables and their indexes, by moving indexes to a
different volume, through use of tablespaces.
As the data are going to be split, I am considering where pg_xlog should go. It is a general well
known advise to keep pg_xlog on a different physi
