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
=?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
Hi, Greg,
On 02 Sep 2004 15:33:38 -0400
Greg Stark <[EMAIL PROTECTED]> wrote:
> Markus Schaber <[EMAIL PROTECTED]> writes:
>
> > logigis=# explain select count(id) from (select ref_in_id as id from streets
> > union select nref_in_id as id from streets) as blubb;
> >
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
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
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
