Elielson Fontanezi <[EMAIL PROTECTED]> writes:
> Hum... What such thing strange.
> Hash algorithms should be better than BTREE and RTREE algorithms.
Perhaps. The problem with Postgres' hash indexes is that no one has
worked on the hash-index code since Berkeley days (except for one or
two minor
Hi!
Thanks for your help!
On Tue, 23 Jul 2002, Gaetano Mendola wrote:
>"Daryl Herzmann" <[EMAIL PROTECTED]> wrote:
>> snet=# select count(valid) from t2002_06;
>> count
>> -
>> 1513895
>
>> snet=# explain SELECT * from t2002_06 WHERE station = 'SGLI4';
>> NOTICE: QUERY PLAN:
>>
>
On Wed, 24 Jul 2002, Daryl Herzmann wrote:
[lots of chopping and rearranging...]
> snet=# explain analyze select * from t2002_06 WHERE station = 'SAMI4';
> Seq Scan on t2002_06 (cost=0.00..35379.69)
> Total runtime: 2452.14 msec
>
> snet=# set enable_seqscan=off;
> snet=# explain analyze select *
24 de julho de 2002 12:46
> Para: Elielson Fontanezi
> Cc: pgsql-sql; pgsql-general
> Assunto: Re: RES: [SQL] Queries not using Index
>
>
> Hi!
>
> Thanks for the help. Please see my responses below.
>
> On Wed, 24 Jul 2002, Elielson Fontanezi wrote:
>
>
> This SELECT causes a sequention scan 'cause your index
> is not HASH type, but likely a BTREE one.
> BTREE index is to interval searches (station = 'SAMI4%')
> not precise searchs. (station = 'SAMI4').
In Postgres, the hash index is slow and inefficient (it's a bit better
in7.3), and I believe
Hi!
Thanks for the help. Please see my responses below.
On Wed, 24 Jul 2002, Elielson Fontanezi wrote:
> What kind of index is t2002_06_station_idx?
snet=# select indexdef from pg_indexes where
indexname='t2002_06_station_idx';
indexdef
On Wed, 24 Jul 2002, Elielson Fontanezi wrote:
> Hi!
>
> What kind of index is t2002_06_station_idx?
> Have you done this SELECT command below, right?
>
> select * from t2002_06 WHERE station = 'SAMI4';
>
> This SELECT causes a sequention scan 'cause your index
> is not H
gt; Cc: Stephan Szabo; [EMAIL PROTECTED]
> Assunto: Re: [SQL] Queries not using Index
>
>
> Hi,
>
> >You _have_ actually run ANALYZE on the table, right?
>
> snet=# vacuum analyze t2002_06;
> VACUUM
> snet=# vacuum analyze;
> VACUUM
> snet=# explain analyz
Hi! :)
On Wed, 24 Jul 2002, Christopher Kings-Lynne wrote:
>Have you tried playing with the statistics gatherer?
Nope. I will look at the docs some and play around. This machine is not
fully production yet. :)
>Also, what is the result of:
>select indexdef from pg_indexes where indexname='t
Have you tried playing with the statistics gatherer?
>From the ANALYZE docs:
"The extent of analysis can be controlled by adjusting the per-column
statistics target with ALTER TABLE ALTER COLUMN SET STATISTICS (see ALTER
TABLE). The target value sets the maximum number of entries in the
most-com
Hi,
>You _have_ actually run ANALYZE on the table, right?
snet=# vacuum analyze t2002_06;
VACUUM
snet=# vacuum analyze;
VACUUM
snet=# explain analyze select * from t2002_06 WHERE station = 'SAMI4';
NOTICE: QUERY PLAN:
Seq Scan on t2002_06 (cost=0.00..35379.69 rows=35169 width=47) (actual
tim
> I inserted the data via 30 "COPY t2002_06 from stdin" (one per
> day) So it
> was grouped by station and then day for each insert. (My script dumped
> the data from each station for the day and then repeated for each station
> and then finally dumped the entire day into the DB. Are you saying
Good evening.
On Tue, 23 Jul 2002, Stephan Szabo wrote:
>Hmm, when the data was put in, was it put in where the same value
>would be bunched up?
I inserted the data via 30 "COPY t2002_06 from stdin" (one per day) So it
was grouped by station and then day for each insert. (My script dumped
On Tue, 23 Jul 2002, Daryl Herzmann wrote:
> Hi!
>
> Thanks for the continued help.
>
> I have attached the results of your request. Thank you!
Hmm, when the data was put in, was it put in where the same value
would be bunched up? IIRC that's a case the optimizer won't realize
if the data isn'
Hi!
Thanks for the continued help.
I have attached the results of your request. Thank you!
Daryl
>Right... sorry about that...
>select * from pg_statistic where starelid=(select oid from pg_class
> where relname='t2002_06';
sql.out.gz
Description: GNU Zip compressed data
---
On Tue, 23 Jul 2002, Daryl Herzmann wrote:
>
> >On Tue, 23 Jul 2002, Daryl Herzmann wrote:
> >
> >> snet=# explain analyze select * from t2002_06 WHERE station = 'SAMI4';
> >> NOTICE: QUERY PLAN:
> >>
> >> Seq Scan on t2002_06 (cost=0.00..35379.69 rows=34979 width=47) (actual
> >> time=67.89..3
>On Tue, 23 Jul 2002, Daryl Herzmann wrote:
>
>> snet=# explain analyze select * from t2002_06 WHERE station = 'SAMI4';
>> NOTICE: QUERY PLAN:
>>
>> Seq Scan on t2002_06 (cost=0.00..35379.69 rows=34979 width=47) (actual
>> time=67.89..3734.93 rows=38146 loops=1)
>> Total runtime: 3748.33 msec
>
On Mon, 22 Jul 2002, Daryl Herzmann wrote:
> snet=# explain SELECT * from t2002_06 WHERE station = 'SGLI4';
> NOTICE: QUERY PLAN:
>
> Seq Scan on t2002_06 (cost=0.00..35379.69 rows=35564 width=47)
>
> EXPLAIN
What does explain show if you do set enable_seqscan=off;
?
It's possible that it's e
"Daryl Herzmann" <[EMAIL PROTECTED]> wrote:
> snet=# select count(valid) from t2002_06;
> count
> -
> 1513895
> snet=# explain SELECT * from t2002_06 WHERE station = 'SGLI4';
> NOTICE: QUERY PLAN:
>
> Seq Scan on t2002_06 (cost=0.00..35379.69 rows=35564 width=47)
Can you do the
Greetings,
I suppose I should have sent this to pgsql-bugs maybe? I would appreciate
it if anybody could help me out. I can't figure out what is going on
here...
snet=# select version();
version
---
(sorry if you get this twice, my first post bounced since I did not use
the subscribed email account. I assume that those messages get
discarded...)
Greetings,
I suppose I should have sent this to pgsql-bugs maybe? I would appreciate
it if anybody could help me out. I can't figure out what
21 matches
Mail list logo
