On Mon, Mar 28, 2011 at 8:30 AM, Stefan Sperling <stsp_at_elego.de> wrote:
> On Mon, Mar 28, 2011 at 08:42:02AM -0400, Greg Stein wrote:
>> On Mar 28, 2011 8:32 AM, "Stefan Sperling" <stsp_at_elego.de> wrote:
>> >
>> > On Mon, Mar 28, 2011 at 07:49:22AM -0400, Greg Stein wrote:
>> > > On Mar 28, 2011 7:41 AM, "Greg Stein" <gstein_at_gmail.com> wrote:
>> > > > Think about how the query optimizer/planner would work. Consider
>> whether a
>> > > result set needs to be constructed.
>> > > >
>> > > > ... a LIMIT 1 provides a ton of help to the SQL engine about what
>> needs to
>> > > be fetched (or not).
>> > > >
>> > > > There is also a semantic element to it. Readers of the code will see
>> that
>> > > you're looking for basic presence rather than a set of results.
>> > > >
>> > > > If/when you need a query containing the set of nodes with mods, then
>> you
>> > > can consider another query. Until that time, the LIMIT is helpful/best.
>> > > >
>> > > > Cheers,
>> > > > -g
>> > >
>> > > In fact, you can switch from selecting local_relpath to a simple 1:
>> > >
>> > > --STMT_ANY_NODES_WITH_PROP_MODS
>> > > SELECT 1 FROM ...
>> > >
>> > > (note stmt name change, too)
>> >
>> > Fair enough. Does r1086208 look better?
>>
>> I like the new names, but the LIMIT didn't make it into the commit :-)
>
> Didn't you imply that SELECT 1 has the same effect as LIMIT 1?
> Or did I misunderstand?
(late joining the conversation)
SELECT 1 doesn't have the same effect as LIMIT 1. I would assume
because you're simply testing row existence, you don't actually need
any data from the row, so you can use SELECT 1 (which would return 1
for every row it encounters). The LIMIT 1 limits the number of rows
the query returns.
So the SELECT 1 determines what data gets return (which you don't care
about), and the LIMIT 1 determines how much data gets returned (of
which you only care about 0 or >0 rows, hence the LIMIT).
-Hyrum
Received on 2011-03-28 15:43:29 CEST