"Pallav Kalva" <[EMAIL PROTECTED]> writes:
> This index would fix this problem but in general I would like to know what if
> there are queries where it does "index scan backwards" and there is no "order
> by clause" and the query is still bad ? Would there be a case like that or the
> planner uses
Thanks! for all your replies, I tried increasing the statistics on
fklistingsourceid to 1000 it made any difference. Then I created an
index on (fklistingsourceid,entrydate) it helped and it was fast.
This index would fix this problem but in general I would like to know
what if there are que
Dean Gibson (DB Administrator) wrote:
The questions are:
1. Why in the planner scanning the entire idx_listing_entrydate, when
I'd think it should be scanning the entire
pk_listingstatus_listingstatusid ?
It's looking at the ORDER BY and sees that the query needs the 10 most
recent, so trie
"Stephen Denne" <[EMAIL PROTECTED]> writes:
> Pallav Kalva asked
> ...
>> and listing0_.fklistingsourceid=5525
> ...
>> order by listing0_.entrydate desc limit 10;
>
>>-> Index Scan Backward using idx_listing_entrydate on
>> listing listing0_ (cost=0.00..781557.28 rows=5118 widt
On 2008-02-12 13:35, Pallav Kalva wrote:
Hi,
...
Table Definitions
\d listing.listingstatus
Table "listing.listingstatus"
Column |Type
| Modifiers
-+-
Pallav Kalva asked
...
> and listing0_.fklistingsourceid=5525
...
> order by listing0_.entrydate desc limit 10;
>-> Index Scan Backward using idx_listing_entrydate on
> listing listing0_ (cost=0.00..781557.28 rows=5118 width=107) (actual
> time=2113544.412..2113544.412 rows=0 l
Hi,
I am using Postgres 8.2.4, we have to regularly run some queries on
some big tables to see if we have any data for a particular request. But
sometimes we might not have any matching rows on a particular request as
in this case, when it cant find any matching rows it pretty much scans
th
