Please CC the list as well as replying directly to me. I don't read this
email address often.
Mihail Nasedkin wrote:
RH> Why do you want an index scan? Do you have any evidence it will be
RH> faster than a sequential scan?
No, but I want to be ready for make Index scan queries in future. I
make f
Die, Richard.
Thank you for answer March, 21 2005 14:15:40:
RH> Mihail Nasedkin wrote:
>> =# explain select * from sites s join site_screens ss on
>> s.oid = ss.id_site;QUERY PLAN
>>
Mihail Nasedkin wrote:
=# explain select * from sites s join site_screens ss on s.oid =
ss.id_site;QUERY PLAN
---
Hash Join (cost=...)
Hash Cond:
Hi,
This may make the query faster.
try to split the query into two parts:
first fetch all list-id's into a temp table (where cr.project_id = '55' and
cr.start_time between '4/4/2003 0:0' and now())
then, join the temp table on lists (where l.list_of_lists_id = '691').
Morten
-Opprinnel
>
> I guess it's a little unclear what to print for the first number when no
> rows are output at all. The code evidently is using the total time spent
> in the plan node, but I think it would be at least as justifiable to
> print a zero instead. Would you have found that less confusing? Anyone
"Chad Thompson" <[EMAIL PROTECTED]> writes:
> Aggregate (cost=2519.58..2519.58 rows=1 width=16) (actual
> time=110715.45..110715.46 rows=1 loops=1)
>-> Nested Loop (cost=0.00..2519.58 rows=1 width=16) (actual
> time=110715.43..110715.43 rows=0 loops=1)
> -> Index Scan using start_
On Thu, 29 May 2003, Chad Thompson wrote:
> I have never been very good at reading these query plans, but I have a bit
> of a problem w/ my query. So any help is appreciated.
>
> The query is fairly self explanitory i think. 2 tables, call_results ( 6.5
> Million records ) and lists ( 11 Million
Keith Bussey <[EMAIL PROTECTED]> writes:
> In trying to figure out just why my ORDER BY queries were so slow, I came
> across something interesting.
The issue here seems to be that Postgres is drastically underestimating
the number of rows that will come out of the indexscan in the second
case:
Since you are selecting all the rows of media, there is no reason to use the
index to do this as it would just slow things down.
Mark
Najm Hashmi wrote:
>
> Hi all,
> I am unable to understand why my inidcies are not used in the query.
> I have following indices:
> index on categories.root
