From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Greg Sabino Mullane" <greg(at)turnstep(dot)com> |
Cc: | pgsql-sql(at)postgresql(dot)org |
Subject: | Re: SQL Challenge: Arbitrary Cross-tab |
Date: | 2004-08-20 03:25:21 |
Message-ID: | 15579.1092972321@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
"Greg Sabino Mullane" <greg(at)turnstep(dot)com> writes:
>> Nope; Gaetano's right, you cannot assume that. It's entirely possible
>> for the planner to choose different plans depending on the OFFSET.
>> (Maybe not very likely, with such small offsets, but could happen.)
> Interesting. I realized that there was a finite chance of different
> plans being chosen, but it seemed neigh-impossible since there is
> no WHERE clause and the offsets only vary from 0-7. What sort of
> different plans would it choose, out of curiosity?
For the particular trivial case you were showing (no WHERE, no GROUP BY,
no ORDER BY, no DISTINCT, no nada) it's probably true that only a
seqscan plan would ever be chosen. I was worrying that people would
take this example and try to add "just that other little thing" to it
and get burnt.
> Are there any particular cases where the same plan is guaranteed to be
> used?
No, I'd never care to make such a guarantee. The planner is entirely
driven by cost estimates. Even if I could say something definitive
about the behavior with the default cost parameters, it wouldn't
necessary hold up when someone had taken an axe to random_page_cost
or something like that. (It's not impossible that the thing would pick
an indexscan plan for even this trivial case, were you to set
random_page_cost below 1.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Richard Huxton | 2004-08-20 07:53:58 | Re: multi column foreign key for implicitly unique columns |
Previous Message | Greg Sabino Mullane | 2004-08-20 02:16:50 | Re: SQL Challenge: Arbitrary Cross-tab |