Re: [PERFORM] The usual sequential scan, but with LIMIT !

2004-09-07 Thread Gaetano Mendola
Pierre-Frédéric Caillaud wrote: Yes, you're right as usual. As usual ? Do you think your father can be wrong on you ? :-) Gaetano ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [PERFORM] The usual sequential scan, but with LIMIT !

2004-09-07 Thread Pierre-Frédéric Caillaud
Yes, you're right as usual. I had not thought about playing with ORDER BY on a field which has only one value in the result set. If you write it as SELECT WHERE topic_id=2 ORDER BY topic_id DESC,id DESC. then an index on (topic_id, id) will work fine. The mixed ASC/DESC ordering is n

Re: [PERFORM] The usual sequential scan, but with LIMIT !

2004-09-07 Thread Tom Lane
=?iso-8859-15?Q?Pierre-Fr=E9d=E9ric_Caillaud?= <[EMAIL PROTECTED]> writes: > suppose I SELECT WHERE topic_id=2 ORDER BY topic_id ASC,id DESC. > Postgres does a seq scan, but it could think a bit more and start at > "first index node which has topic_id>2" (simple to find in a btree) th

Re: [PERFORM] The usual sequential scan, but with LIMIT !

2004-09-06 Thread Pierre-Frédéric Caillaud
OK, thanks a lot for your explanations. Knowing how the planner "thinks", makes it pretty logical. Thank you. Now another question... I have a table of records representing forum posts with a primary key (id), a topic_id, a timestamp, and other fields which I won't detail. I want t

Re: [PERFORM] The usual sequential scan, but with LIMIT !

2004-09-06 Thread Tom Lane
=?iso-8859-15?Q?Pierre-Fr=E9d=E9ric_Caillaud?= <[EMAIL PROTECTED]> writes: > Now, if I LIMIT the query to 10 rows, the index should be used all the > time, because it will always return few rows... well, it doesn't ! Not at all. From the planner's point of view, the LIMIT is going to reduce the

Re: [PERFORM] The usual sequential scan, but with LIMIT !

2004-09-06 Thread Dennis Bjorklund
On Mon, 6 Sep 2004, [iso-8859-15] Pierre-Frédéric Caillaud wrote: > Why is it that way ? The planner should use the LIMIT values when > planning the query, should it not ? And it do use limit values, the estimated cost was lower when you had the limit, What you need to do is to tune pg

Re: [PERFORM] The usual sequential scan, but with LIMIT !

2004-09-06 Thread Pierre-Frédéric Caillaud
Update : select * from apparts where departement=69 order by departement limit 10; does use an index scan (because of the ORDER BY), even with OFFSET, and it's a lot faster. ---(end of broadcast)--- TIP 9: the planner will ignore your desire to cho

[PERFORM] The usual sequential scan, but with LIMIT !

2004-09-06 Thread Pierre-Frédéric Caillaud
Hello, I have this table : CREATE TABLE apparts ( id SERIAL NOT NULL PRIMARY KEY, priceFLOAT NOT NULL, surfaceINTEGER NOT NULL, price_sq FLOAT NOT NULL, roomsINTEGER NULL, vente