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
"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
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
