X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 659A05E46C0 for ; Fri, 20 Aug 2004 00:25:16 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 08650-05 for ; Fri, 20 Aug 2004 03:25:23 +0000 (GMT) Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by svr1.postgresql.org (Postfix) with ESMTP id 6F3375E46DB for ; Fri, 20 Aug 2004 00:25:14 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.12.11/8.12.11) with ESMTP id i7K3PLXY015580; Thu, 19 Aug 2004 23:25:21 -0400 (EDT) To: "Greg Sabino Mullane" Cc: pgsql-sql@postgresql.org Subject: Re: SQL Challenge: Arbitrary Cross-tab In-reply-to: References: Comments: In-reply-to "Greg Sabino Mullane" message dated "Fri, 20 Aug 2004 02:16:50 -0000" Date: Thu, 19 Aug 2004 23:25:21 -0400 Message-ID: <15579.1092972321@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.0 tagged_above=0.0 required=5.0 tests= X-Spam-Level: X-Archive-Number: 200408/223 X-Sequence-Number: 18720 "Greg Sabino Mullane" 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