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_status>3 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
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 issues
[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
> I understand that the 2.6.* kernels are much better at large memory
> support (with respect to performance issues), so unless you have a
> 64-bit machine lying around - this is probably worth a try.
>
> You may need to build a new kernel with the various parameters :
>
> CONFIG_NOHIGHMEM
> CONFIG
[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 u
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 distribu
> >>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 change this hitting?
>
> Upgrade to 64-bit processors + 64-bit linux.
Does
Kaloyan Iliev Iliev <[EMAIL PROTECTED]> writes:
> Will ANALYZE resove this?
Try it and find out.
regards, tom lane
---(end of broadcast)---
TIP 8: explain analyze is your friend
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
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
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
Hi,
I am asking the prev. question because there is no change in the query
plan (as far as I see) but the mem usage decreases from 258M to 16M.
Kaloyan Iliev
Tom Lane wrote:
Kaloyan Iliev Iliev <[EMAIL PROTECTED]> writes:
I have the following problem. A week ago we've migrated f
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
"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 zufrid
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 debug
[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.
--
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 boot
Hi to
all,
I have a query which counts how many elements I have in the
database.
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_endk
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 i
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 RE
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 of
21 matches
Mail list logo
