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:
>>
>
> 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! :)
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
13 matches
Mail list logo
