Here is my query, that returns one row:
SELECT f1, f2,(SELECT dfield FROM d WHERE d.ukey = f1) FROM m WHERE
status IN(2) AND jid IN(17674) ORDER BY pkey DESC LIMIT 25 OFFSET 0;
Here was the really bad plan chosen. This didn't come back for a long
while and had to be cancelled:
On Sat, Jun 26, 2004 at 04:58:16PM +0800, Christopher Kings-Lynne wrote:
>
> >>Let see in contrib/ the application pg_who ... you will see the process,
> >>the queries, and the CPU ... ;o)
>
> Even easier:
>
> SELECT * FROM pg_stat_activity;
>
> As a superuser.
Thanks!
That works as needed!
Usually, when you post a request like this, you should provide
something a little more concrete (the CREATE TABLE statement for that table,
with
Since you didn't, I'll posit something that sounds like what
you're using, and take a stab at your problem.
TABLE Prices (
stock
VARCHAR(
P.A.M. van Dam wrote:
Hi!
I'd like to know if there is a way to see what queries are running
within a certain postgres instance and how much resources (cpu/memory)
etc. they are using. Right now it's impossible to see what is happening
within postgres when it's binaries are using 100% CPU.
In Syba
Litao Wu <[EMAIL PROTECTED]> writes:
> Since there are multiple databases and
> there are 170 postgres processes this morning,
> 60 of them are access the problem database,
> and 57 of 60 are non-idle.
> We only need to gdb those 57 processes, or
> we need gdb 60 or 170?
Potentially the deadlock
Thanks!
OK, we will do this exceise next time.
TSince there are multiple databases and
there are 170 postgres processes this morning,
60 of them are access the problem database,
and 57 of 60 are non-idle.
We only need to gdb those 57 processes, or
we need gdb 60 or 170?
Thanks again!
--- Tom
Litao Wu <[EMAIL PROTECTED]> writes:
> Our PG version is 7.3.2.
Hmm. On general principles you should be using 7.3.6, but I do not see
anything in the 7.3.* change logs that looks very likely to cure this.
> The copy process is always there. Besides copy
> process, there are many select processe
Hi Tom,
Our PG version is 7.3.2.
The copy process is always there. Besides copy
process, there are many select processes wait also
(it is understandable only when reindex,
but how come selects wait when drop/create index?
>From Postgres doc:
Note: Another approach to dealing with a corrupted
user
Title: RE: [PERFORM] postgres 7.4 at 100%
Creating indexes on a table affects insert performance depending on the number of indexes that have to be populated. From a query standpoint, indexes are a godsend in most cases.
Duane
-Original Message-
From: Chris Cheston [mailto:[EMAIL P
Litao Wu <[EMAIL PROTECTED]> writes:
> It happened again.
> This time it hangs when we drop/create index.
> Here is gdb info with --enable-debug postgres.
Well, that pretty much removes all doubt: something has left the buffer
context lock (cntx_lock) set on a buffer that certainly ought to be fr
Hi All,
It happened again.
This time it hangs when we drop/create index.
Here is gdb info with --enable-debug postgres.
Thank you for your help!
postgres 24533 24327 2 Jun28 ?00:39:11
postgres: postgres
xxx xxx.xxx.x.xxx COPY waiting
postgres 23508 24327 0 03:23 ?00:00:00
po
> Can I get any better performance?
You can try bumping your sort memory way up (for this query only).
Another method would be to cluster the table by the symbol column
(eliminates the expensive sort).
If you could run a very simple calculation against open & close numbers
to eliminate a majorit
Thanks this query works for what I want. So here is an output of the
explain analyze:
QUERY
PLAN
---
I see - thanks very much. I created an index for column 'oid' which I
was using in a WHERE. So rule of thumb- create an index for column(s)
which I use in WHERE queries.
So to speak. They can also sometimes assist in sorting. The OID column
is special. I suggest adding a unique index to that c
I see - thanks very much. I created an index for column 'oid' which I
was using in a WHERE. So rule of thumb- create an index for column(s)
which I use in WHERE queries.
Thanks,
Chis
On Wed, 30 Jun 2004 15:30:52 +0800, Christopher Kings-Lynne
<[EMAIL PROTECTED]> wrote:
>
>
> > Why would I or w
Why would I or would I not create multiple indexes in a table? I
created another index in the same table an it's improved performance
even more.
You create indexes when you need indexes. Indexes are most helpful when
they match the WHERE clause of your selects.
So, if you commonly do one query
Oh my, creating an index has absolutely reduced the times it takes to
query from around 700 ms to less than 1 ms!
Thanks so much for all your help. You've saved me!
One question:
Why would I or would I not create multiple indexes in a table? I
created another index in the same table an it's imp
17 matches
Mail list logo
