Re: query performance

From: Alban Hertroys <dalroi(at)solfertje(dot)student(dot)utwente(dot)nl>
To: pepone(dot)onrez <pepone(dot)onrez(at)gmail(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: query performance
Date: 2008-01-17 09:40:00
Message-ID: 46940304-080A-441E-B070-C665102CCC0C@solfertje.student.utwente.nl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Jan 14, 2008, at 3:58 AM, pepone.onrez wrote:

> I have this query in a table with 150 thowsand tuples and it takes
> to long
>
> t_documentcontent._id AS _id
> FROM t_documentcontent LIMIT 50 OFFSET 80000

You want an ORDER BY there. Not only will it probably speed things
up, without it there's no guaranteed order in the results returned.

As table records have no specific order and updates and inserts on
that table take the first free position, you risk ending up showing
some records twice in your set (same id on different 'pages') and
missing others because you've already skipped past them when there's
concurrent access.

There's still some risk for that if you order, but as you seem to
order on a sequence-generated column, updates aren't a problem for
you and inserts end up at the end anyway. But only if you order them.

Alban Hertroys

--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.

!DSPAM:737,478f1e139491365710960!

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Reg Me Please 2008-01-17 10:48:24 Accessing composite type columns from C
Previous Message Achilleas Mantzios 2008-01-17 08:21:33 Re: postgresql in FreeBSD jails: proposal