I recently upgraded to 7.2 from 7.1.
Prior to 7,2, I was shutting down the database, droping indexes,
vacuuming analayze, re-building all the indexes on a nightly basis ( all
automated of course ;) ). Things ran fine.
After upgrading to 7.2, I replaced all that with a nightly on-line
/usr/l
explain, but the rows value is weird.
Thanks,
Michael
Tom Lane wrote:
[EMAIL PROTECTED]">
"Michael G. Martin" <[EMAIL PROTECTED]> writes:
Here is what I would expect which usually happens:
explain select * from symbol_data where symbol_name=
where symbol_name='GE';
NOTICE: QUERY PLAN:
Index Scan using symbol_data_pkey on symbol_data (cost=0.00..513.09 rows=128
width=129)
EXPLAIN
vpm=> select count(*) from symbol_data where symbol_name='GE';
count
---
5595
Tom Lane wrote:
[EMAIL PROTECTED]">
) = .0125%
--Michael
Tom Lane wrote:
[EMAIL PROTECTED]">
"Michael G. Martin" <[EMAIL PROTECTED]> writes:
Here is what is actually there:
select count(*) from symbol_data where symbol_name='ELTE'; 687
Hmm. Do you have
Heh--i was gonna ask why the strange percent representation in the stats
table.
I just ran a vacuum analyze with the specific column. Still get the same
explain plan:
Seq Scan on symbol_data (cost=0.00..709962.90 rows=369782 width=129)
--Michael
Tom Lane wrote:
[EMAIL PROTECTED]">
I sai
G,MKC,AEN,BAC,BDX,BKF,BRT}
| {0.023,0.018,0.0027,0.0017,0.0017,0.0013,0.0013,0.0013,0.0013,0.0013}
| {A,BRN,DPAC,FUTR,INTC,MDSN,OCA,RAA,SSYS,USTB,_^^VPM} | 0.112971
(1 row)
I'll alter and play with the table tomorrow and let you know what I find.
-Michael
Tom Lane wrote:
[EMAIL PROTECTED]&q
ime: 137.55 msec
Even though the optimizer thinks the index will cost more, it does pick it
and use it with the performance expected when enable_seqscan = off;
-Michael
Tom Lane wrote:
[EMAIL PROTECTED]">
"Michael G. Martin" <[EMAIL PROTECTED]> writes:
I just ran a
chael
[EMAIL PROTECTED]">
Tom Lane wrote:
[EMAIL PROTECTED]">
"Michael G. Martin" <[EMAIL PROTECTED]> writes:
I just ran a vacuum analyze with the specific column. Still get the same explain plan:
Did the pg_stat
I've had this happen on 2 seperate servers now.
After reading the docs, I bumped up shared_buffers. On one machine with
2G pyhsical ram, I set the param to use 1G of memory ( 131072 value), on
another machine with 800M of RAM, I set the value to about 500M ( 64000
). ipcs shows the correct a
I read an earlier post by Tom where he recommends 1/4 of physical ram.
I will go to 1/5 to be safe and I assume it will be ok. I'm guessing
my 50% was probably overkill.
--Michael
Michael G. Martin wrote:
> I've had this happen on 2 seperate servers now.
>
> After
I had an issue where my index was not always used on a very large table.
The issue came down to the data distribution and not pulling in enough of
a random sample to get an accurate estimate ( I think the default max value
was around 3000 sample rows ( 300 * 10 default_samples -- see analyze.c
11 matches
Mail list logo
