On Tue, 19 Aug 2008, Mark Wong wrote:
Hi all,
We started an attempt to slice the data we've been collecting in
another way, to show the results of software vs. hardware RAID:
http://wiki.postgresql.org/wiki/HP_ProLiant_DL380_G5_Tuning_Guide#Hardware_vs._Software_Raid
The angle we're trying to
Hi all,
We started an attempt to slice the data we've been collecting in
another way, to show the results of software vs. hardware RAID:
http://wiki.postgresql.org/wiki/HP_ProLiant_DL380_G5_Tuning_Guide#Hardware_vs._Software_Raid
The angle we're trying to show here is the processor utilization a
Am 19.08.2008 um 16:49 schrieb Scott Carey:
What is your work_mem set to? The default?
Try increasing it significantly if you have the RAM and seeing if
that affects the explain plan. You may even want to set it to a
number larger than the RAM you have just to see what happens. In
all
What is your work_mem set to? The default?
Try increasing it significantly if you have the RAM and seeing if that
affects the explain plan. You may even want to set it to a number larger
than the RAM you have just to see what happens. In all honesty, it may be
faster to overflow to OS swap spac
Thanx alot... its solved my problem
On Mon, Aug 18, 2008 at 8:50 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> [ please keep the list cc'd for the archives' sake ]
>
> "Gauri Kanekar" <[EMAIL PROTECTED]> writes:
> > On Mon, Aug 18, 2008 at 7:32 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> >> No PG relea
Am 19.08.2008 um 14:17 schrieb Matthew Wakeling:
On Tue, 19 Aug 2008, Moritz Onken wrote:
tablename| attname | n_distinct | correlation
result | domain | 1642 | 1
Well, the important thing is the correlation, which is 1, indicating
that Postgr
On Tue, 19 Aug 2008, Moritz Onken wrote:
tablename| attname | n_distinct | correlation
result | domain | 1642 | 1
Well, the important thing is the correlation, which is 1, indicating that
Postgres knows that the table is clustered. So I have no
As far as I can tell, it should. If it is clustered on an index on
domain, and then analysed, it should no longer have to sort on domain.
Could you post here the results of running:
select * from pg_stats where attname = 'domain';
schemaname | tablename| attname | null_fra
On Tue, 19 Aug 2008, Moritz Onken wrote:
explain select
a."user", b.category, sum(1.0/b.cat_count)::float
from result a, domain_categories b
where a."domain" = b."domain"
group by a."user", b.category;
Both results and domain_categories are clustered on domain and analyzed.
Why is it still sor
Am 18.08.2008 um 18:05 schrieb Matthew Wakeling:
On Mon, 18 Aug 2008, Moritz Onken wrote:
Running the query for more than one user is indeed not much slower.
That's what I need. I'm clustering the results table on domain
right now. But why is this better than clustering it on "user"?
The
10 matches
Mail list logo
