Vitaly,
> I am in the middle of going through them all, till now disabling the
> enable_mergejoin really helped.
In that case, your random_page_cost is probably too low. Check the ratio of
per-tuple times on index vs. seqscan seeks.
--
-Josh Berkus
Aglio Database Solutions
San Francisco
Hello Manfred,
I thank everyone for helping me on this - So many tips.
I am in the middle of going through them all, till now disabling the
enable_mergejoin really helped.
Also, I agree that the design might be flawed (I could use triggers
and stuff like that) but for now I am just comparing how
On Thu, 29 Apr 2004 13:36:47 -0400, Rod Taylor <[EMAIL PROTECTED]> wrote:
>The reason for the function is that the sort routines (hash aggregation
>included) will not stop in mid-sort
Good point.
Servus
Manfred
---(end of broadcast)---
TIP 9: the
On Thu, 2004-04-29 at 13:13, Manfred Koizar wrote:
> On Wed, 28 Apr 2004 08:23:35 -0400, Rod Taylor <[EMAIL PROTECTED]> wrote:
> >The below plpgsql forces the kind of algorithm we wish the planner could
> >choose. It should be fairly quick irregardless of dataset.
>
> That reminds me of hash aggre
On Wed, 28 Apr 2004 08:23:35 -0400, Rod Taylor <[EMAIL PROTECTED]> wrote:
>The below plpgsql forces the kind of algorithm we wish the planner could
>choose. It should be fairly quick irregardless of dataset.
That reminds me of hash aggregation. So here's another idea for Vitaly:
SELECT b
> Rod, he has a hierarchy of genres. Genre 1 has 6379 child genres and a
> book can be in more than one of these.
bookgenres.genre_id = genre_children.genre_child_id AND
genre_children.genre_id = 1
I see, sorry. I didn't notice the genre_child_id in the where clause.
First glance had t
On Tue, 27 Apr 2004 18:01:34 -0400, Rod Taylor <[EMAIL PROTECTED]> wrote:
>On Tue, 2004-04-27 at 17:27, Vitaly Belman wrote:
>> Hello pgsql-performance,
>>
>> I discussed the whole subject for some time in DevShed and didn't
>> achieve much (as for results). I wonder if any of you guys can hel
Vitaly,
I'm afraid that your helper on DevShed is right; 7.5 for Windows is still in
development, we've not even *started* to check it for performance yet.
Since the Merge Join is taking 90% of your query time, I might suggest
increasing shared_buffers and sort_mem to see if that helps.
--
On Tue, 2004-04-27 at 17:27, Vitaly Belman wrote:
> Hello pgsql-performance,
>
> I discussed the whole subject for some time in DevShed and didn't
> achieve much (as for results). I wonder if any of you guys can help
> out:
>
> http://forums.devshed.com/t136202/s.html
You're taking the w
Hi,
You can try some variation:
SELECT
book_id
FROM
bookgenres, genre_children
WHERE
bookgenres.genre_id = genre_children.genre_child_id AND
genre_children.genre_id = 1
GROUP BY book_id
LIMIT 10
The next works if the 'genre_child_id' is UNIQUE on the 'genre_children'
table.
SELEC
Vitaly Belman wrote:
Hello pgsql-performance,
I discussed the whole subject for some time in DevShed and didn't
achieve much (as for results). I wonder if any of you guys can help
out:
http://forums.devshed.com/t136202/s.html
So cutting and pasting:
- SCHEMA -
CREATE TABLE bv_bookge
Hello pgsql-performance,
I discussed the whole subject for some time in DevShed and didn't
achieve much (as for results). I wonder if any of you guys can help
out:
http://forums.devshed.com/t136202/s.html
Regards,
Vitaly Belman
ICQ: 1912453
AIM: VitalyB1984
MSN: [EMAIL PROTECTED]
12 matches
Mail list logo
