I have a table with with an index that is of type 'timestamp without
time zone'. Multiple records are inserted per second so the index is not
unique.
This table experiences frequent inserts and updates. Bulk deletes are
performed once per month.
Slower than expected search times are experienced w
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:
Hello, pgsql-sql.
I have customize simple query with join two tables:
=# \d sites
Таблица "public.sites"
Колонка | Тип | Модификаторы
-+--
ists_id = '691').
Morten
-Opprinnelig melding-
Fra: Chad Thompson [mailto:[EMAIL PROTECTED]
Sendt: 29. mai 2003 19:20
Til: pgsql-sql
Emne: [SQL] Index scan never executed?
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 app
>
> 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
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 records )
weblink=# explain analyze
weblink-# selec
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:
Greetings,
I have stumbled upon a confusing aspect of PostgreSQL queries involving ORDER
BY.
In trying to figure out just why my ORDER BY queries were so slow, I came
across something interesting.
First, let me give you 2 very similar queries:
1) SELECT p.uid
FROM client_profiles p
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
Hi all,
I am unable to understand why my inidcies are not used in the query.
I have following indices:
index on categories.root
index on media.category
unique index on categories.id
Here is my query :
mondo=# explain select m.id
form media m, categories c
14 matches
Mail list logo
