> "Rangachari Anand" <[EMAIL PROTECTED]> writes:
> > We are running Postgres 7.0.3 on a Linux machine with a 2.4.0 kernel.
> > We have noticed that as we run our application which does
> > a lot of updates that CPU utilization (by postmaster) gradually
> > increases as time passes.
>
> Try 7.1.2 -
>Date: Wed, 20 Jun 2001 23:06:56 -0500
>To: "Rainer Mager" <[EMAIL PROTECTED]>
>From: Steven Lane <[EMAIL PROTECTED]>
>Subject: RE: High memory usage
>Cc: [EMAIL PROTECTED]
>Bcc:
>X-Attachments:
>
>>Hi,
>>
>> Hmm, I'm not sure I understand how I could use EXISTS in my query.
>>Can you
>>give
"Rangachari Anand" <[EMAIL PROTECTED]> writes:
> We are running Postgres 7.0.3 on a Linux machine with a 2.4.0 kernel.
> We have noticed that as we run our application which does
> a lot of updates that CPU utilization (by postmaster) gradually
> increases as time passes.
Try 7.1.2 --- if it sti
"Ross J. Reedstrom" <[EMAIL PROTECTED]> writes:
> My guess is it's an interaction of the optimizer with the plan for this
> query, which might have many, nearly identical cost plans, since 8 of
> the 9 tables are actually the same table.
Yes, I suspect the same. A large fraction of the possible
This looks very promising. I'll have to look over it and try a few things
out but I think it puts me on the right track.
Thanks!
--Rainer
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, June 21, 2001 10:56 AM
> To: Rainer Mager
> Cc: PostgreSQL Admin
>
"Rainer Mager" <[EMAIL PROTECTED]> writes:
> First, this type of query seems to use exponential amounts of memory.
Hmm. What does EXPLAIN show as the plan for the query? How long does
it take to do the EXPLAIN? If the EXPLAIN alone takes a lot of time/
space, then you need to reduce the size o
Thanks for the reply.
I can try to explain the query but it is being generated semi-automatically
so it is not hard coded for a particular purpose. Before going into the
explanation, though, I have a litte bit of new information. First, it is
ONLY the join condition that matters, the other param
If you look farther down that same dump, you'll see a CREATE RULE
that looks something like:
CREATE RULE AS ON SELECT
CREATE RULE "_RETincluded_works" AS ON SELECT TO "included_works" DO
INSTEAD SELECT "works"."uuid", "works"."title" as "lhs" [...]
In other words, pg_dump, especially before 7
My guess would be that it's being dumped as a table with
an ON SELECT rule (the internal form of the view). IIRC,
7.1's pg_dump is smarter about this.
Check for a CREATE RULE for the table.
On Tue, 19 Jun 2001, Gerard Mason wrote:
> Anybody?
>
>
> "Gerard Mason" <[EMAIL PROTECTED]> wrote in
Hi,
if ant is already installed, you have to set two environment variables to
run ant successfully.
The first one is: %ANT_HOME%
This one has to point to the directory where ANT is installed. It contains a
bin
directory and an lib directory. In the bin directory resides the batch file.
In the
http://pgreplicator.sourceforge.net/
Haven't used it. Don't know.
cheers,
thalis
On Wed, 20 Jun 2001, Matt Doughty wrote:
> Is there anyeay to replicate servers using postgres 7.1.1? I can't find
> Rserv or anything like it in the contrib tree.
>
> TIA,
>
> Matt
>
>
Ranier -
Can you explain in words what this query is supposed to be doing?
I'm guessing, from the DISTINCT, and the use of multiple occurances of
the same table, that the result you want can be gotten at in some other
way, that lets the backend be smarter about how it does it. Since it _is_
rele
Hello, again.
Is there some way to turn off notices in postgres's logging? We have a
sloppy programmer who wrote queries that cause postgres to print
messages like:
Adding missing FROM-clause entry for table "table_name"
This application is used by hundreds of our customers, and hence gets lot
More info on this...
First, this type of query seems to use exponential amounts of memory. I
tried a join with 10 pieces (the one below with 9 used ~60MB) and it went up
immediately to ~ 390MB usage and has been sitting there at 100% CPU usage
for more than 10 minutes. This is on a database with a
Hi,
Here is a query that demonstrates the problem. Running this takes about
60MB until it is done at which time it is freed (I was wrong when I said
otherwise earlier). Interestingly, the same amount of memory is used when
doing an EXPLAIN on this query. Also it happens to return 0 rows. P
15 matches
Mail list logo
