On Sat, Jun 26, 2010 at 01:19:57PM -0400, Robert Haas wrote:
>
> I'm not sure. What does seem clear is that it's fundamentally at odds
> with the "admission control" approach Kevin is advocating. When you
> start to run short on a resource (perhaps memory), you have to decide
> between (a) waiting for memory to become available and (b) switching
> to a more memory-efficient plan. The danger of (b) is that using less
> memory probably means using more of some other resource, like CPU or
> disk, and now you've just switched around which release you're
> overloading - but on the other hand, if the difference in CPU/disk is
> small and the memory savings is large, maybe it makes sense. Perhaps
> in the end we'll find we need both capabilities.
>
> I can't help feeling like some good instrumentation would be helpful
> in answering some of these questions, although I don't know where to
> put it.
One issue with this is that no matter how expensive you make a query,
it will run - it just may take a very long time (if the cost is a
reasonable estimate)
This is also an implied suggestion for a dynamically self-modifying cost
param, since the memory cost isn't absolute, but rather relative to free
memory. In addition, as Robert points out, the tradeoff between
resources is dynamic, as well.
Hmm, I'm suddenly struck by the idea of having a max_cost parameter,
that refuses to run (or delays?) queries that have "too high" a cost.
That might have some interactive-SQL uses, as well: catch the cases you
forgot a join condition, so have an unintended cartesian explosion, etc.
Could also be a belt-and-suspenders last defense for DB admins who
aren't sure the client software completely stops the users from doing
something stupid.
Clearly, default to current behavior, -1 (infinity).
Ross
--
Ross Reedstrom, Ph.D. reedstrm@rice.edu
Systems Engineer & Admin, Research Scientist phone: 713-348-6166
The Connexions Project http://cnx.org fax: 713-348-3665
Rice University MS-375, Houston, TX 77005
GPG Key fingerprint = F023 82C8 9B0E 2CC6 0D8E F888 D3AE 810E 88F0 BEDE
