Hallo,
versuche von 8.4 auf 9.4 zu migrieren und habe bei einem Index welcher in der alten Version funktioniert hat Probleme:
CREATE INDEX users_hash_idx ON users USING btree (md5(((((id || ‘’::text) || (email)::text) || ‘’::text) || created))); --> ERROR: functions in index expression must be marked IMMUTABLE
Irgendwelche Ideen wieso der Index auf 9.4 den Fehler auswirft …???
Besten Dank.
Michael
zeig mal die Tabellen- und indexdefinition von 8.4.
Btw.: warum migrierst Du auf 9.4? Und im Betreff sogar 9.2?
Hallo -> produktiv läuft auf einem altem debian mit 8.4 die datenbank soll nun auf einem centos 7 laufen und die 9.2 ist hier "out of the box, aber natürlich kann ich auch auf eine neuere version gehen wenn es an der 9.2 liegt 9.4 war ein tippfehler.
Besten Dank
CREATE INDEX users_hash_idx ON users USING btree (md5(((((id || ‘’::text) || (email)::text) || ‘’::text) || created)));
CREATE TABLE users (
id integer DEFAULT nextval(‘users_id_seq’::regclass) NOT NULL,
name character varying(30) NOT NULL,
surname character varying(30) NOT NULL,
email character varying(255) NOT NULL,
password character varying(128) NOT NULL,
status smallint NOT NULL,
permission_id integer,
created timestamp with time zone DEFAULT now() NOT NULL,
created_by integer NOT NULL,
modified timestamp with time zone,
modified_by integer,
approved timestamp with time zone,
approved_by integer,
phone character varying(30),
type smallint NOT NULL,
lang character varying(2) NOT NULL,
company character varying(30),
reseted boolean
);
Danke !!!
ahhh…
das createt-Feld ist mit Zeitzone, daher davon abhängig, mit welcher Zeitzone das grad läuft. Daher kann kein valider Index auf diese Art und weise erstellt werden. Einer der vielen Fehler, die 8.4 noch hatte und nun gefixt sind.
Davon abgesehen erscheint mir der Index relativ sinnfrei, wozu soll der gut sein?
Hallo,
Danke für die rasche Info hatte mir schon so etwas gedacht … leider ist das eine Datenbank zu einem zugekauften Kundenportal keine Ahnung wozu der Index gut ist … gibt es eine Möglichkeit das zu umschiffen … eigentlich ist UTC eingestellt … jedoch habe ich bis dato kaum postgres verwendet und deswegen sehr 
Besten Dank
Wenn das zugekauft ist habt ihr ja sicher Support, oder? Ich würde an Eurer Stelle den kontaktieren.
Hat 8.4 eigentlich schon pg_stat_user_indexe?
Hallo,
die scheint es zu geben:
66541 | 116437 | public | dashboard | dashboard_code_key | 0 | 0 |
0
66541 | 116439 | public | dashboard | dashboard_pkey | 0 | 0 |
0
66551 | 116441 | public | dashboard_template | dashboard_template_idx | 0 | 0 |
0
66551 | 116443 | public | dashboard_template | dashboard_template_pkey | 0 | 0 |
0
66559 | 116445 | public | dashboard_template_widget | dashboard_template_widget_idx | 0 | 0 |
0
66570 | 116447 | public | image | image_pkey | 0 | 0 |
0
66578 | 116449 | public | permission | permission_pkey | 0 | 0 |
0
66583 | 116451 | public | permission_role | permission_role_pkey | 0 | 0 |
0
66589 | 116453 | public | role | role_description_idx | 0 | 0 |
0
66589 | 116455 | public | role | role_name_idx | 0 | 0 |
0
66589 | 116457 | public | role | role_pkey | 0 | 0 |
0
66598 | 116459 | public | role_policy | role_policy_pkey | 0 | 0 |
0
66604 | 116461 | public | users | users_email_key | 0 | 0 |
0
66604 | 116463 | public | users | users_pkey | 0 | 0 |
0
66618 | 116465 | public | users_role | users_role_user_id_role_id_idx | 0 | 0 |
0
66624 | 116467 | public | widget | widget_pkey | 0 | 0 |
0
66583 | 116469 | public | permission_role | permission_role_permission_id_idx | 0 | 0 |
0
66583 | 116470 | public | permission_role | permission_role_role_id_idx | 0 | 0 |
0
66598 | 116471 | public | role_policy | role_policy_role_id_idx | 0 | 0 |
0
66589 | 116472 | public | role | role_status_idx | 0 | 0 |
0
66604 | 116473 | public | users | users_hash_idx | 0 | 0 |
0
66612 | 116474 | public | users_login | users_login_idx | 0 | 0 |
0
66618 | 116475 | public | users_role | users_role_user_id_idx | 0 | 0 | 0
leider gibt es die bude nicht mehr und das ding ist so stark gewachsen … das alte lied halt … die Frage wäre halt wie groß ist der Impact ohne diesen Index …
Vielen Dank.
Ich hab es mal vereinfacht nachgebaut:
test=*# create table demo_tz(id serial, ts1 timestamptz default now());
CREATE TABLE
test=*# create index idx_demotz on demo_tz(md5(ts1::text));
FEHLER: Funktionen im Indexausdruck müssen als IMMUTABLE markiert sein
und einen häßlich würgaround gebaut:
test=*# create or replace function tstz2text(timestamptz) returns text as $$begin return ($1 at time zone 'utc')::text; end;$$language plpgsql immutable;
CREATE FUNCTION
test=*# create index idx_demotz on demo_tz(md5(tstz2text(ts1)));
CREATE INDEX
Das ganze geht natürlich schief, wenn da unterschiedliche Zeitzonen drin sind.
Vermutlich kannst Du den Index auch einfach weglassen, aber das sollte der Hersteller der Software Dir bestätigen. Du könntest in pg_stat_user_indexes nachschauen, ob der Index überhaupt in Nutzung war/ist.
66604 | 116473 | public | users | users_hash_idx | 0 | 0 | 0
Index ist nie benutzt worden.
wohin kann ich nun die Rechnung schicken? 
ins ösiland … besten dank