Hi Frederik,
I'm running minutely updates on south-east asia. The DB is comparably
small. After I did this:
On 07.08.2011 21:19, Frederik Ramm wrote:
DROP INDEX planet_osm_ways_nodes;
DROP INDEX planet_osm_rels_parts;
CREATE INDEX planet_osm_ways_nodes ON planet_osm_ways USING gin (nodes)
On 07.08.2011 21:19, Frederik Ramm wrote:
To be a bit clearer on the procedure to fix things: Either re-import, or
re-create indexes with
DROP INDEX planet_osm_ways_nodes;
DROP INDEX planet_osm_rels_parts;
CREATE INDEX planet_osm_ways_nodes ON planet_osm_ways USING gin (nodes)
WITH
Hi,
Stephan Knauss wrote:
On 07.08.2011 21:19, Frederik Ramm wrote:
To be a bit clearer on the procedure to fix things: Either re-import, or
re-create indexes with
DROP INDEX planet_osm_ways_nodes;
DROP INDEX planet_osm_rels_parts;
CREATE INDEX planet_osm_ways_nodes ON planet_osm_ways USING
On 09.08.2011 00:00, Frederik Ramm wrote:
Stephan Knauss wrote:
This did lead to huge problems on my DB as it was still using the
intarray for the updates.
I don't understand. The intarray/no intarray question is completely
unrelated to the fastupdate on/off question?
The problem was that
Hi,
Stephan Knauss wrote:
The problem was that the INDEX is different. It has the gin__int_ops
included on my installation with intarray in place.
Ah, now I see. My instructions on rebuilding the index were not taking
the old style into account. Sorry, I overlooked that!
So, anyone else
Hi,
this is about a bug in osm2pgsql that will affect you if you
* run diff updates (--slim --append)
* run PostgreSQL 8.4 or 9.0
* use an osm2pgsql SVN revision = 25198 (2011-01-31) and 26475 (today)
* are not using non-standard index tablespaces (-i or
--tablespace-slim-index)
Running
Frederik Ramm frede...@remote.org wrote:
this is about a bug in osm2pgsql that will affect you if you
* run diff updates (--slim --append)
* run PostgreSQL 8.4 or 9.0
* use an osm2pgsql SVN revision = 25198 (2011-01-31) and 26475 (today)
* are not using non-standard index tablespaces
Hi,
Sven Geggus wrote:
Removing the double negative here this will read as:
If you are using standard index tablespaces
Yes, that's what I said ;)
I supose this bug is the cause for the problems many people
(including myself) where talking abount on this list in the last few
months.
I
Frederik Ramm frede...@remote.org wrote:
To be a bit clearer on the procedure to fix things: Either re-import, or
re-create indexes
Hm, am I right in the assumption that this problem will affect any index
of type gin not just the two created by osm2pgsql?
I wonder if my hstore tags-column
9 matches
Mail list logo
