Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id 55DC61337B68 for ; Thu, 16 Dec 2010 16:30:34 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024) with ESMTP id 44509-03 for ; Thu, 16 Dec 2010 20:30:27 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from na3sys009aog113.obsmtp.com (na3sys009aog113.obsmtp.com [74.125.149.209]) by mail.postgresql.org (Postfix) with SMTP id 3B196133655C for ; Thu, 16 Dec 2010 16:30:25 -0400 (AST) Received: from source ([209.85.210.177]) by na3sys009aob113.postini.com ([74.125.148.12]) with SMTP ID DSNKTQp24Qw7mufAGJzPZWNucVlQJ2jeebj0@postini.com; Thu, 16 Dec 2010 12:30:26 PST Received: by mail-iy0-f177.google.com with SMTP id 21so2063048iyj.22 for ; Thu, 16 Dec 2010 12:30:25 -0800 (PST) Received: by 10.231.33.198 with SMTP id i6mr6744991ibd.10.1292527406290; Thu, 16 Dec 2010 11:23:26 -0800 (PST) From: Michael Holt References: <001f01cb9d56$13d69790$3b83c6b0$@devshock.com> In-Reply-To: <001f01cb9d56$13d69790$3b83c6b0$@devshock.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcudVWq9DKLKRaRwRb+9F4g65/D4MQAANVEw Date: Thu, 16 Dec 2010 11:23:25 -0800 Message-ID: Subject: Re: using limit To: Anibal David Acosta , pgsql-admin@postgresql.org Content-Type: multipart/alternative; boundary=0022152d84a1ea192904978bfc03 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-4.199 tagged_above=-10 required=5 tests=BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3 X-Spam-Level: X-Archive-Number: 201012/114 X-Sequence-Number: 36343 --0022152d84a1ea192904978bfc03 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable This really depends on the type of query you=92re talking about. If there= =92s only one row in the table you=92re querying then no, I don=92t think it=92l= l change anything. If you=92re querying a single row using a primary key it shouldn=92t change anything. If you=92re doing an aggregate query, say a su= m of a bunch of rows, it also won=92t improve performance. If you=92re doing a query on a table with multiple rows and not filtering b= y a primary key or other unique index then yes, it will improve the query. *From:* pgsql-admin-owner@postgresql.org [mailto: pgsql-admin-owner@postgresql.org] *On Behalf Of *Anibal David Acosta *Sent:* Thursday, December 16, 2010 11:19 AM *To:* pgsql-admin@postgresql.org *Subject:* [ADMIN] using limit Hi I really like to do efficient SQL queries so, my question is if I am expecting no more than one row from a select, using the LIMIT 1 could improve the performance? If I use my logic, the LIMIT 1 instruction tell to postgres that stop searching when found 1 record, but maybe it is unnecessary Thanks Anibal --0022152d84a1ea192904978bfc03 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

This really depends on the type of query you=92re talking about. If there= =92s only one row in the table you=92re querying then no, I don=92t think i= t=92ll change anything. If you=92re querying a single row using a primary k= ey it shouldn=92t change anything. If you=92re doing an aggregate query, sa= y a sum of a bunch of rows, it also won=92t improve performance.

=A0

If you=92re doing a query on a= table with multiple rows and not filtering by a primary key or other uniqu= e index then yes, it will improve the query.

=A0

From: pgsql-admin-owner@postgre= sql.org [mailto:pgs= ql-admin-owner@postgresql.org] On Behalf Of Anibal David Acosta<= br> Sent: Thursday, December 16, 2010 11:19 AM
To: pgsql-admin@postgresql.org
Sub= ject: [ADMIN] using limit

=A0

Hi

I really like to= do efficient SQL queries so, my question is if I am expecting no more than= one row from a select, using=A0 the LIMIT 1 could improve the performance?=

=A0

If I use my logic, the= LIMIT 1 instruction tell to postgres that stop searching when found 1 reco= rd, but maybe it is unnecessary

=A0

=A0

Thanks

=A0

Anibal

--0022152d84a1ea192904978bfc03--