Hi all!
I have such table:
CREATE TABLE object (
id SERIAL,
object_type_id int8
);
This table has 4 000 000 rows.
There are 2 index:
CREATE INDEX object_id_idx ON object(id);
CREATE INDEX object_object_type_id_idx ON object(object_type_id);
So:
# EXPLAIN SELECT * FROM object WHERE id =
Title: Message
Hi,
I have an objectid
field of type bigint, but when I run queries like:
select * from table
where objectid=123;
index is not used on
objectid even though it's declared.
However when I
run:
select * from table
where objectid='123';
index is
used.
Is there an
option I can
Hi,
Stephan Szabo wrote:
> On Tue, 16 Oct 2001, CoL wrote:
>
>
>>---
>>The 2 table query, where prog_data has ~8800 rowsn and index on prog_id:
>>bash-2.04$ time echo "explain select distinct
>>prog_id,prog_ftype,prog_fcasthour,prog_date from prog_dgy_xy,prog_data
>>w
> > Hmm, does the explain change if you vacuum analyze the other table
> > (prog_data)? If not, what does explain show if you do a
> > set enable_seqscan='off';
> > before it?
Did you do the vacuum analyze on the other table (prog_data) as well?
It seems to be overestimating the number of joined
Hi,
I did not make vacuum analyze ;), the vacuum once now:
vacuumdb -Uuser -ddb -v -tprog_dgy_xy
NOTICE: --Relation prog_dgy_xy--
NOTICE: Pages 20935: Changed 0, reaped 0, Empty 0, New 0; Tup 921013:
Vac 0, Keep/VTL 0/0, Crash 0, UnUsed 0, MinLen 178, MaxLen 184;
Re-using: Free/Avail. Spac
I forget:
select version();
version
-
PostgreSQL 7.1.3 on i386-unknown-freebsd4.3, compiled by GCC 2.95.3
It seems that there are index using problems in 7.1.3 ?
(checkin same problem in comp.dat
On Tue, 16 Oct 2001, CoL wrote:
> ---
> The 2 table query, where prog_data has ~8800 rowsn and index on prog_id:
> bash-2.04$ time echo "explain select distinct
> prog_id,prog_ftype,prog_fcasthour,prog_date from prog_dgy_xy,prog_data
> where pxygy_pid=prog_id " | psql -U
On Mon, 15 Oct 2001, Szabo Zoltan wrote:
> Hi,
>
> I have that:
>
> 1)
> db=> explain select pxygy_pid from prog_dgy_xy where pxygy_pid=12121;
> NOTICE: QUERY PLAN:
>
> Group (cost=0.00..29970.34 rows=921 width=4)
>-> Index Scan using progdgyxy_idx2 on prog_dgy_xy
> (cost=0.00..29947.3
Hi,
I have that:
1)
db=> explain select pxygy_pid from prog_dgy_xy where pxygy_pid=12121;
NOTICE: QUERY PLAN:
Group (cost=0.00..29970.34 rows=921 width=4)
-> Index Scan using progdgyxy_idx2 on prog_dgy_xy
(cost=0.00..29947.32 rows=9210 width=4)
than:
2)
db=> explain select pxygy_pid fro
I want to query this...
--> SELECT * FROM bbs ORDER BY ref desc, step ASC LIMIT 12;
this query doesn't refer the index that made by this query.
--> CREATE INDEX idx_bbs ON bbs (ref, step);
but, i change the query that "ref desc" to "ref asc".
then query refer the index, and i can see a result
I want to query this...
--> SELECT * FROM bbs ORDER BY ref desc, step ASC LIMIT 12;
this query doesn't refer the index that made by this query.
--> CREATE INDEX idx_bbs ON bbs (ref, step);
but, i change the query that "ref desc" to "ref asc".
then query refer the index, and i can see a result v
"Kim Yunhan" <[EMAIL PROTECTED]> writes:
> I want to query this...
> --> SELECT * FROM bbs ORDER BY ref desc, step ASC LIMIT 12;
> this query doesn't refer the index that made by this query.
> --> CREATE INDEX idx_bbs ON bbs (ref, step);
Well, no. The ordering the query is asking for has nothi
I want to query this...
--> SELECT * FROM bbs ORDER BY ref desc, step ASC LIMIT 12;
this query doesn't refer the index that made by this query.
--> CREATE INDEX idx_bbs ON bbs (ref, step);
but, i change the query that "ref desc" to "ref asc".
then query refer the index, and i can see a result
Peter Eisentraut <[EMAIL PROTECTED]> writes:
>> But it hasn't got done yet. (Peter, would it be
>> easy to make GUC handle this? There'd need to be some way to cause
>> guc.c to do a putenv() ...)
> I thought pg_control was the place for this. Any idea how long a locale
> string can legally be
Patrik Kudo <[EMAIL PROTECTED]> writes:
> select * from elever where userid like 'walth%'; <-- Not OK!
> Droping and recreating the index solves the problem, but that's not
> good enough for me since the problem has reoccured on a different
> machine with a different database. vacuum and vacuum a
Hi!
We're using postgres 6.5.3 for an application where we, among other
things, store information about users. On two separate occations on
two different servers we've experienced problems with indices on the
same table (out of over 100).
The problem is that postgres refuse to find a certain row
16 matches
Mail list logo
