Stephan Szabo <[EMAIL PROTECTED]> writes:
> Actually, just thought of something else. If you remove
> the probably redundant p.song_id=s.song_id from the second
> query (since the join ... using should do that) does it
> change the explain output?
I was just about to point that out. The WHERE
Actually, just thought of something else. If you remove
the probably redundant p.song_id=s.song_id from the second
query (since the join ... using should do that) does it
change the explain output?
On Fri, 9 Mar 2001, David Olbersen wrote:
> On Fri, 9 Mar 2001, Stephan Szabo wrote:
>
> ->As
Darn. Well, one of the queries picked that 1 row was going to survive
the nested loop step and the other said 14. I was wondering which one
was closer to being correct at that time.
On Fri, 9 Mar 2001, David Olbersen wrote:
> On Fri, 9 Mar 2001, Stephan Szabo wrote:
>
> ->As a question, how
On Fri, 9 Mar 2001, Stephan Szabo wrote:
->As a question, how many rows does
->select * from playlist p join songs s using (song_id) where
->p.waiting=TRUE;
->actually result in?
Well it depends. Most of the time that playlist table is "empty" (no rows where
waiting = TRUE), however users can (i
On Fri, 9 Mar 2001, David Olbersen wrote:
> On Fri, 9 Mar 2001, Stephan Szabo wrote:
>
> -> Hmm, what were the two queries anyway?
>
> The "slower" query
>
> SELECT
> to_char( p.insertion_time, 'HH:MI AM MM/DD' ) as time_in,
> s.nameas title,
>
On Fri, 9 Mar 2001, Stephan Szabo wrote:
-> Hmm, what were the two queries anyway?
The "slower" query
SELECT
to_char( p.insertion_time, 'HH:MI AM MM/DD' ) as time_in,
s.nameas title,
a.nameas artist,
s.length as le
> On Fri, 9 Mar 2001, Stephan Szabo wrote:
>
> ->Not entirely. Those are only estimates, so they don't entirely line up
> ->with reality. Also, I notice the first estimates 14 rows and the second
> ->1, which is probably why the estimate is higher. In practice it probably
> ->won't be signif
On Fri, 9 Mar 2001, Stephan Szabo wrote:
->Not entirely. Those are only estimates, so they don't entirely line up
->with reality. Also, I notice the first estimates 14 rows and the second
->1, which is probably why the estimate is higher. In practice it probably
->won't be significantly diffe
On Fri, 9 Mar 2001, David Olbersen wrote:
> Greetings,
> I've been toying aroudn with postgres 7.1beta5's ability to control the
> planner via explicitely JOINing tables. I then (just for giggles) compare the
> difference in the EXPLAIN results.
>
> I'm no super-mondo-DBA or anything, b
