Here's the new stats since the vacuum on that column--quite a few changes.
select * from pg_stats where tablename = 'symbol_data' and attname ='symbol_name';
tablename | attname | null_frac | avg_width | n_distinct |
most_common_vals |
"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_stats data change noticeably?
ANALYZE is a statistical sampling process in 7.2, so I'd expect the
results to move around somewhat each time you
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
Sorry, I missed your bottom part before I replied last.
The table breakdown consists of about 8000 symbol_names with at most 5000
rows of data for each symbol ( stock market history ).
So, those sample percents seem huge. The most any symbol would have would
be about 5000 / (8000*5000) = .01
I said:
>> symbol_data | symbol_name | 0 | 7 | 152988 |
>> {EBALX,ELTE,LIT,OEX,RESC,BS,ESH,HOC,IBC,IDA} |
>>
>{0.018,0.017,0.0017,0.0017,0.0017,0.0013,0.0013,0.0013,0.0013,0.0013}
>
>> | {A,BMO,DBD,FSCHX,IIX,MAS,NSANY,PTEC,SR,UTIL,_^^
yes. each symbol_name only gets one row added and maybe a few updated each
market day.
This is interesting too. Planner thinks 128 rows on this symbol, GE, yet
there are really 5595. Not as off as ELTE, but a large factor. at least
the index get hit here.
explain select * from symbol_data
"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 reason to think that that was also true when you last
did VACUUM ANALYZE or VACUUM?
> Here is the pg_stat query:
> select *
Hi Tom,
Here is what is actually there:
select count(*) from symbol_data where symbol_name='ELTE';
count
---
687
Here is the pg_stat query:
select * from pg_stats where tablename = 'symbol_data' and attname ='symbol_name';
tablename | attname | null_frac | avg_width | n_d
"Michael G. Martin" <[EMAIL PROTECTED]> writes:
> Here is what I would expect which usually happens:
> explain select * from symbol_data where symbol_name='IBM';
> Index Scan using symbol_data_pkey on symbol_data (cost=0.00..512.99 rows=128
>width=129)
> Here is one that fails:
> explain sele
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
I wrote:
> [ In psql, COPY from stdin fails to report referential integrity errors ]
> After further investigation I'm still unsure where to pin the blame.
> What the backend is actually sending back is
> C COPY -- completion tag for COPY
> E errmsg-- error detected
Reinhard Max <[EMAIL PROTECTED]> writes:
> It has a unique index on id, non-unique indexes on all othe columns,
> and contains approx. 35 rows.
Do you actually *need* an index on every single column? How many of
those columns are you actually going to use for searches on a frequent
basis?
C
Hi,
I am not sure whether the behaviour described below is to be expected
or to be considered as a bug, but I bet you can tell me ;)
I have a table defined as follows:
CREATE TABLE "foo" (
"id" int NOT NULL,
"name" character varying(256) NOT NULL,
"street" character vary
Jean-Paul ARGUDO <[EMAIL PROTECTED]> writes:
> ERROR: SearchSysCache: Bad cache id 27
Seen it before...
This is not a bug, it is a broken installation. You are trying to
invoke a 7.1 plpgsql in a 7.2 backend.
regards, tom lane
---(end of broadc
> > ERROR: SearchSysCache: Bad cache id 27
> This is not a bug, it is a broken installation. You are trying to
> invoke a 7.1 plpgsql in a 7.2 backend.
Right analysis Tom!
createlang with old plpgsql.so ...
had to drop functions / triggers using old plpgsql.so (thanks to a select on
pg_proc)
15 matches
Mail list logo
