On Mar 28, 2011 7:41 AM, "Greg Stein" <gst...@gmail.com> wrote: > > > On Mar 28, 2011 7:32 AM, "Stefan Sperling" <s...@elego.de> wrote: > > > > On Sat, Mar 26, 2011 at 09:46:48AM -0400, Greg Stein wrote: > > > If it only needs to detect a single row, then LIMIT 1 should be in the > > > query. > > > > Is there really a significant difference between LIMIT 1 and not stepping > > through more than one result row? > > > > I'd rather keep the queries reusable for contexts where a complete > > list of modified nodes is required, instead of adding COUNT() (as > > suggested elsewhere) or LIMIT 1. > > 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) Cheers, -g
