Hi,
I have the following problem. A week ago we've migrated from PGv7.2.3 to
7.4.6. There were a lot of things in the apps to chenge but we made
them. But one query doesn't want to run. In the old PGv7.2.3 it passes
for 10 min. In the new one it gaves:
DBD::Pg::st execute failed: ERROR: out
On Fri, 14 Jan 2005 12:32:12 -0600
Adrian Holovaty [EMAIL PROTECTED] wrote:
If I have this table, function and index in Postgres 7.3.6 ...
CREATE TABLE news_stories (
id serial primary key NOT NULL,
pub_date timestamp with time zone NOT NULL,
...
)
CREATE OR REPLACE
Kaloyan Iliev Iliev [EMAIL PROTECTED] writes:
I have the following problem. A week ago we've migrated from PGv7.2.3 to
7.4.6. There were a lot of things in the apps to chenge but we made
them. But one query doesn't want to run. In the old PGv7.2.3 it passes
for 10 min. In the new one it
Hi to
all,
I have a query which counts how many elements I have in the
database.
SELECT count(o.id) FROM orders
oINNER JOIN report r ON
o.id=r.id_orderINNER JOIN status s ON
o.id_status=s.idINNER JOIN contact c ON
o.id_ag=c.idINNER JOIN endkunde e ON
o.id_endkunde=e.idINNER JOIN
I inferred this from reading up on the compressed vm project. It can be
higher or lower depending on what devices you have in your system --
however, I've read messages from kernel hackers saying Linux is very
aggressive in reserving memory space for devices because it must be
allocated at
[EMAIL PROTECTED] wrote:
Since the optimal state is to allocate a small amount of memory to
Postgres and leave a huge chunk to the OS cache, this means you are
already hitting the PAE penalty at 1.5GB of memory.
How could I chang this hitting?
Upgrade to 64-bit processors + 64-bit linux.
Thanks,
It worked. I have read in the docs what this enable_hashagg do, but I
couldn't understand it. What does it change?
From the Doc:
---
enable_hashagg (boolean)
Enables or disables the query planner's use of hashed aggregation
plan types. The default is on. This is used for
Andrei Bintintan [EMAIL PROTECTED] writes:
SELECT count(o.id) FROM orders o
INNER JOIN report r ON o.id=r.id_order
INNER JOIN status s ON o.id_status=s.id
INNER JOIN contact c ON o.id_ag=c.id
INNER JOIN endkunde e ON o.id_endkunde=e.id
INNER JOIN zufriden z ON
Frank Wiles wrote:
Adrian Holovaty [EMAIL PROTECTED] wrote:
If I have this table, function and index in Postgres 7.3.6 ...
CREATE TABLE news_stories (
id serial primary key NOT NULL,
pub_date timestamp with time zone NOT NULL,
...
)
CREATE OR REPLACE FUNCTION
Kaloyan Iliev Iliev [EMAIL PROTECTED] writes:
It worked. I have read in the docs what this enable_hashagg do, but I
couldn't understand it. What does it change?
Your original 7.4 query plan has several HashAgg steps in it, which are
doing aggregate/GROUP BY operations. The planner thinks that
Try :
EXPLAIN SELECT get_year_trunc(pub_date) as foo FROM ... GROUP BY foo
Apart from that, you could use a materialized view...
db=# EXPLAIN SELECT DISTINCT get_year_trunc(pub_date) FROM
Ah, that makes sense. So is there a way to optimize SELECT DISTINCT
queries
that have no
Tom Lane wrote:
I wouldn't recommend turning off hashagg as a permanent solution, it
was just a quickie to verify my suspicion of where the memory was going.
Hi,
How to understant the upper sentence? I shouldn't turn hashagg off
permanently for this query or for the entire database. For now I
Amrit,
It's not useless, it's just not optimal.
All operating systems, FC2, FC3, will have the same problem with
greater than 4G of memory on a 32 bit processor.
The *only* way to avoid this is to go to a 64 bit processor (opteron)
and then
for greater performance use a linux
[EMAIL PROTECTED] wrote:
Does the PAE help linux in handling the memory of more than 4 Gb limit in
32 bit
archetech ? My intel server board could handle the mem of 12 Gb [according to
intel spec.] and if I use Fedora C2 with PAE , will it useless for mem of more
than 4Gb.?
Any comment please?
I
[EMAIL PROTECTED] wrote:
In the standard rpm FC 2-3 with a newly install server , would it
automatically
detect and config it if I use the mechine with 4 Gb [6Gb.] or should I
manually config it?
Amrit
Thailand
Good question. I dont have FC2-3 here to check. I recommend firing off a
question to
My experience is RH9 auto detected machines = 2GB of RAM and installs
the PAE bigmem kernel by default. I'm pretty sure the FC2/3 installer
will do the same.
[EMAIL PROTECTED] wrote:
I understand that the 2.6.* kernels are much better at large memory
support (with respect to performance
I have to do all the joins because in the where cause I can also have other
conditions that are related to the other tables.
For example:
WHERE o.id_status3 AND o.id_ag=72 AND v.id_worker=5 AND z.id=10.
Now if these search functions are IN then the query runs faster.
One thing I could do at
17 matches
Mail list logo
