On Mon, Apr 11, 2011 at 7:25 PM, Kevin Grittner <Kevin.Grittner@xxxxxxxxxxxx> wrote: > Gerhard Hintermayer <gerhard.hintermayer@xxxxxxxxx> wrote: > >> Because tests & docs say so: >> > http://www.postgresql.org/docs/9.0/static/continuous-archiving.html#CONTINUOUS-ARCHIVING-CAVEATS > > I asked because I didn't remember any mention of hashed indexes. I > still don't know for sure that you have any, much less that you have > so many that it makes sense to reindex the entire database. > > Or are you saying you've seen a problem with indexes of other types? > > -Kevin > I have e.g. a table with: Table "public.auftrag_l1" Column | Type | Modifiers ------------+------------------------+----------- a_nr | integer | sub_nr | integer | ch_nr_ofm | real | case_nr | integer | datum | date | zeit | time without time zone | dauer | integer | print | text | format | character(1) | gramm | real | brand | text | outrate | smallint | reliab | smallint | tech | character varying(3) | gramm_dekl | real | ch_nr_fl | real | ch_nr | real | fuell_gew | real | p_code | text | Indexes: "idx_auftrag_l1" hash (a_nr) when I do query this table on the newly awakened primary with something like a_nr=1234, I get an empty result, but when I query all tuples and manually search for the one with a_nr=1234, I see that the tuple is there. Seeing this and reading the docs about the caveats I see no other solution as to REINDEX all of my DB's :-( I have lot's of tables with primary key a_nr as above (though I know it is not reflected in the table definition, but should result in the same result, i.e. a_nr integer PRIMARY KEY would create an index to lookup the table). Gerhard -- Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
