[EMAIL PROTECTED] wrote:
> The above query takes 5 seconds to execute!
>
> [...]
>
> Total runtime: 96109.571 ms
It sure doesn't look like it...
> Total runtime: 461.907 ms
>
> [...]
>
> Suddenly the query takes only 0.29 seconds!
How are you timing this, really?
/* Steinar */
--
Homepage:
> -Original Message-
> From: Tim Jones [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, May 23, 2006 12:11 AM
> To: pgsql-performance@postgresql.org
> Subject: [PERFORM] slow query using sub select
>
> Hi,
> I am having a problem with a sub select query being kinda slow. The
> query is as f
"Tim Jones" <[EMAIL PROTECTED]> writes:
> I am having a problem with a sub select query being kinda slow. The
> query is as follows:
> select batterycode, batterydescription, observationdate from Battery t1
> where patientidentifier=611802158 and observationdate = (select
> max(observationdate
Hi,
I am having a problem with a sub select query being kinda slow. The
query is as follows:
select batterycode, batterydescription, observationdate from Battery t1
where patientidentifier=611802158 and observationdate = (select
max(observationdate) from Battery t2 where t2.batterycode=t1.batt
Hi Craig,Thanks for your response. This did start recently and it wasn't after a kernel update, but it was after we moved the db from Machine B to Machine A (which have slightly different kernel versions). However, the problem took about a week to show up after we moved from one machine to the ot
Meetesh Karia wrote:
Hi all,
We've recently started having a problem where a query that normally
executes in ~15ms starts to take upwards of 20s to complete. When the
connection that ran query is returned to the connection pool, it appears
as though a transaction is still in progress so the
Hi all,We've recently started having a problem where a query that normally executes in ~15ms starts to take upwards of 20s to complete. When the connection that ran query is returned to the connection pool, it appears as though a transaction is still in progress so the connection pool tries to can
The problem is that the planner is guessing horribly at what the nodes
will return, and I'm betting the reason for that is your join criteria.
Why are you joining on fields that are concatenated together, instead of
just joining on the fields themselves? That's a sure-fire way to confuse
the planne
Hi, Cstendis,
Cstdenis wrote:
> Server is a dual xeon with a gig of ram dedicated mostly to postgresql.
> Here is the changed lines in my postgresql.conf: http://pastebin.ca/57222
3M is really low for a production server.
Try using pg_pool and limiting it to about 30 or so backend connections,
On Sun, May 21, 2006 at 02:01:14PM -0600, Brendan Duddridge wrote:
> When the query planner uses the indexes with the concatenated values
> and the where clause, the query can be sub-second response times (but
> not always depending on the category_id value). By just doing a
> regular join as
On Fri, May 19, 2006 at 07:37:45PM -0700, Kenji Morishige wrote:
> Where can I find any documentation to partition the tablespace disk files onto
> different physical arrays for improved performance?
Other than CREATE TABLESPACE??
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
On Fri, May 19, 2006 at 03:56:49PM -0700, Cstdenis wrote:
> (Its been a hour and I dont see my message on the list so I'm sending it
> again. I've moved the queries and analyze out of the email incase it was
> rejected because too long)
>
> query: http://pastebin.ca/57218
>
> In the pictures ta
On Fri, 2006-05-19 at 21:37, Kenji Morishige wrote:
> Where can I find any documentation to partition the tablespace disk files onto
> different physical arrays for improved performance?
There have been quite a few posts to this list in the past about this,
so searching it might be a good start.
13 matches
Mail list logo
