Hello,
O.k. this is the wrong query, but it still shows the odd slowness. I am
going to test the full dataset on FC2 and see what happens.
J
On Mon, 2005-03-21 at 10:58 -0800, Joshua D. Drake wrote:
> Hello,
>
> O.k. here is a great one for you. Here are some further comparisons:
>
> 8.0.1 FC3
Hello,
O.k. here is a great one for you. Here are some further comparisons:
8.0.1 FC3 64bit:
foo=# explain analyze SELECT t.topic_id, t.topic_title, t.topic_status,
t.topic_replies, t.topic_time, t.topic_type, t.topic_vote,
t.topic_last_post_id, f.forum_name, f.forum_status, f.forum_id,
f.auth_v
Tom Lane wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
O.k. I got 7.3.9 to operate as expected on FC2 (64bit) and these are my
results:
enable_hashagg on:
HashAggregate (cost=80.00..82.50 rows=1000 width=404) (actual
time=209.746..209.750 rows=1 loops=1)
You got co
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> O.k. I got 7.3.9 to operate as expected on FC2 (64bit) and these are my
> results:
> enable_hashagg on:
> HashAggregate (cost=80.00..82.50 rows=1000 width=404) (actual
> time=209.746..209.750 rows=1 loops=1)
You got confused somewhere along the
On 7.4 and up you may have to set enable_hashagg = off to force a
Sort/GroupAggregate plan instead of HashAggregate.
O.k. on FC2 7.4.6 64bit I get:
-
HashAggregate (cost=80.00..82.50 rows=
Tom Lane wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
Let me know what you come up with. Thanks for the help.
Hmph. On my FC3 machine, 7.4 is consistently faster than 7.3 in sorting
and grouping this data --- it's about 710 vs 960 msec. (This is on a P4
1.8GHz, presumably slower t
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Let me know what you come up with. Thanks for the help.
Hmph. On my FC3 machine, 7.4 is consistently faster than 7.3 in sorting
and grouping this data --- it's about 710 vs 960 msec. (This is on a P4
1.8GHz, presumably slower than your machines.)
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>> Hm. What is the data like --- in particular, are the topic_ids unique
>> in the data processed by the sort?
>>
> Yes topic_ids are the primary key. Here is the nuke_bbtopics structure:
Hmmm ... because p.post_id has only a single value allowed by
The rest are pretty basic integers.
Hm. What is the data like --- in particular, are the topic_ids unique
in the data processed by the sort?
Yes topic_ids are the primary key. Here is the nuke_bbtopics structure:
Column| Type |
Modifiers
-
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> The aggregation is a great deal worse as well. I suspect that for some
>> reason the comparison operations involved in the sorting and grouping
>> are much slower on the FC3 machine. What are the data types of the
>> leading sort
Well I definately did a initdb --no-locale
34 bin/initdb -D cdata --no-locale
But I didn't specify LC_COLLATE or LC_CTYPE explicitly.
I did set LANG="C" in /etc/sysconfig/i18n however.
Just to be specific...
show all from psql:
lc_collate | C
lc_ctype
Tom Lane wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
If you look at the second line in each explain it is the sort that is
causing the grief.
The aggregation is a great deal worse as well. I suspect that for some
reason the comparison operations involved in the sorting and groupi
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> If you look at the second line in each explain it is the sort that is
> causing the grief.
The aggregation is a great deal worse as well. I suspect that for some
reason the comparison operations involved in the sorting and grouping
are much slower
Specs:
7.3.6 machine Dual Athlon MP
2 GIG of ram,
4 Drive IDE (3ware) RAID 10
OS FC1 with 2.4 kernel
7.4.6 machine Dual Opteron MP (64bit PostgreSQL),
2 Gig of Ram
10 Drive RAID 10 with 128 Meg battery backed cache (3WARE).
OS FC3 x86_64 with 2.6 kernel
Essentials parameters:
7.3.6:
sha
14 matches
Mail list logo
