pg.ddx.io  pgsql-sql@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Franco Bruno Borghesi <franco@akyasociados.com.ar>
To: Andras Kutrovics <n-drew@freemail.hu>
Cc: pgsql-sql@postgresql.org
Subject: Re: Simple SQL Question
Date: Tue, 09 Nov 2004 13:53:01 -0300
Message-ID: <4190F5ED.1010808@akyasociados.com.ar> (raw)
In-Reply-To: <41908AE6.80202@freemail.hu>
References: <418BB051.6070808@freemail.hu>
	<1099678157.39887.15.camel@taz.oficina>
	<41908AE6.80202@freemail.hu>

Didn't know about the seqscan problem when using ORs. But you still can 
split the query in two, and then use Union to join the results:

SELECT .... WHERE itemKey=:lastItemKey AND location>:lastLocation
UNION
SELECT ... WHERE itemKey>:lastItemKey


You could solve the OFFSET/LIMIT modification problem if you could keep 
the transaction open, but I don't know if it's applicable in your case.


Andras Kutrovics wrote:

> Franco Bruno Borghesi wrote:
>
>
> Hi!
>
> Sorry for being late with the answer, I was busy at one of our customer;)
>
>> wouldn't it be easier using offset & limit?: you always select from 
>> the table with an itemkey,location order by clause. You save the 
>> current offset between requests, and for every request you re-execute 
>> the query with a different offset.
>
>   Sure, but sometimes I have to query by name, and dont want to create
>   another query component.
>
>> If you still want to go with what you already have, you should keep 
>> the lastItemKey and lastLocaltion values between requests, and your 
>> where clause should be something like:
>> WHERE (itemKey=:lastItemKey AND location>:lastLocation) OR 
>> (itemKey>:lastItemKey)
>
>
>   It works perfectly, but I have to consider the performance issue,
>   because if i use 'or' statement, postgres doesn't use index scan,
>   and I also have tables with 3 or more keys and 500.000 records , where
>   the performance of this method is poor.
>   Maybe I will end up using limit and offset in case of incremental
>   fetching,but if the table is modified between requests, it can behave
>   weird.
>   Is there a perfect solution to this?
>
> Sorry for the english
>
> Thank you again,
>
> Andras Kutrovics
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
>               http://archives.postgresql.org
>




view thread (19+ messages)  latest in thread

Message-ID: <4190F5ED.1010808@akyasociados.com.ar>
Permalink:  ../4190F5ED.1010808@akyasociados.com.ar/
Also on:    postgresql.org/message-id/4190F5ED.1010808@akyasociados.com.ar

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-sql@postgresql.org
  Cc: franco@akyasociados.com.ar, n-drew@freemail.hu
  Subject: Re: Simple SQL Question
  In-Reply-To: <4190F5ED.1010808@akyasociados.com.ar>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox