[PERFORM] Bad performance with hashjoin

Here's the query: --- SELECT * FROM bv_reviews r, bv_votes v WHERE r.vote_id = v.vote_id AND v.book_id = 113 --- bv_votes has around 7000 rows with

[PERFORM] Performance hit on loading from HD

I have a problem with certain queries performance. Trouble is that while their execution plan is pretty good and mostly their execution is great as well, their FIRST execution time (that is after you mount the database) is abysmal. I realize that it happens due to the loading of data from the HD

Re: [PERFORM] Visual Explain

Is it possible to download the Visual Explain only (link)? I only see that you can donwload the whole ISO (which I hardly need). On Thu, 17 Jun 2004 13:52:15 +0100, Paul Thomas [EMAIL PROTECTED] wrote: On 17/06/2004 12:10 Adam Witney wrote: Will this run on other platforms? OSX maybe?

Re: [PERFORM] Visual Explain

I see. Thanks :). On Thu, 17 Jun 2004 18:35:11 +0100, Paul Thomas [EMAIL PROTECTED] wrote: On 17/06/2004 17:54 Vitaly Belman wrote: Is it possible to download the Visual Explain only (link)? I only see that you can donwload the whole ISO (which I hardly need). You can get it from CVS

Re: [PERFORM] Additional select fields in a GROUP BY

=58466 width=47) Sort Key: s.series_id, s.series_name, s.series_picture Which eventually almost doubles the execution time. On Sun, 13 Jun 2004 08:52:12 -0500, Bruno Wolff III [EMAIL PROTECTED] wrote: On Sun, Jun 13, 2004 at 06:21:17 +0300, Vitaly Belman [EMAIL PROTECTED

[PERFORM] Additional select fields in a GROUP BY

(IIRC)? I believe that in such cases MySQL does first() by itself. Other ideas are welcome too. Regards, Vitaly Belman ICQ: 1912453 AIM: VitalyB1984 MSN: [EMAIL PROTECTED] Yahoo!: VitalyBe ---(end of broadcast)--- TIP 3: if posting/reading

[PERFORM] PostgreSQL on VMWare vs Windows vs CoLinux

for their advices regarding the emulations. Regards, Vitaly Belman ICQ: 1912453 AIM: VitalyB1984 MSN: [EMAIL PROTECTED] Yahoo!: VitalyBe ---(end of broadcast)--- TIP 8: explain analyze is your friend

Re: [PERFORM] PostgreSQL caching

-- Regards, Vitaly Belman ICQ: 1912453 AIM: VitalyB1984 MSN: [EMAIL PROTECTED] Yahoo!: VitalyBe Wednesday, May 26, 2004, 1:24:18 AM, you wrote: MS Vitaly, MS This looks like there might be some room

Re: [PERFORM] PostgreSQL caching

=\... Naturally I could eventually do data coupling to gain perforemnce boost if this issue will not be solved in other ways. I'll keep your idea in mind anyway, thanks. Once again thanks for you feedback. Regards, Vitaly Belman ICQ: 1912453 AIM: VitalyB1984 MSN: [EMAIL PROTECTED] Yahoo

Re: [PERFORM] PostgreSQL caching

= outer.book_id) Thank you for your try. Regards, Vitaly Belman ICQ: 1912453 AIM: VitalyB1984 MSN: [EMAIL PROTECTED] Yahoo!: VitalyBe Friday, May 21, 2004, 11:10:56 PM, you wrote: MS Not knowing a whole lot about the internals of Pg, one thing jumped out MS

[PERFORM] PostgreSQL caching

if refreshing the page would be really quick, sine Postgre already loaded the data to memory). P.S If the query or its EXPLAIN are critical for a better understanding, let me know. Regards, Vitaly Belman ICQ: 1912453 AIM: VitalyB1984 MSN: [EMAIL PROTECTED] Yahoo!: VitalyBe

[PERFORM] Simply join in PostrgeSQL takes too long

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