On Mon, Mar 28, 2011 at 8:30 AM, Stefan Sperling <s...@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" <s...@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" <gst...@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
