On a related note: There was a change between PostgreSQL 8.3 and 8.4
which increased the default_statistics_target from 10 to 100 and its
maximum from 1.000 to 10.000 which makes ANALYZE runs take longer but
at least for me it helps a lot.
Have you, too, noticed the 10% performance
On Sat, Sep 19, 2009 at 7:42 PM, Jochen Topf joc...@remote.org wrote:
(I beleive it used to vacuum, but I don't immediately see it in the
current source).
I always disabled autovacuum for this kind of database. It tends to always
come at the wrong time. Its better to do the vacuum once after
1. Doing a vacuum immediately after the import isn't useful, there is
nothing to vacuum by definition.
While this is true an ANALYZE should still be done to initialize the statistics.
2. Doing a vacuum after a diff is also useless, since the vacuum will
probably takes much much longer than
On Sun, Sep 20, 2009 at 6:16 PM, Lars Francke lars.fran...@gmail.com wrote:
1. Doing a vacuum immediately after the import isn't useful, there is
nothing to vacuum by definition.
While this is true an ANALYZE should still be done to initialize the
statistics.
Which it does, but ANALYZE is
Hi,
Lars Francke wrote:
On a related note: There was a change between PostgreSQL 8.3 and 8.4
which increased the default_statistics_target from 10 to 100 and its
maximum from 1.000 to 10.000 which makes ANALYZE runs take longer but
at least for me it helps a lot.
Have you, too, noticed the
On Sun, Sep 20, 2009 at 7:43 PM, Frederik Ramm frede...@remote.org wrote:
Hi,
Lars Francke wrote:
On a related note: There was a change between PostgreSQL 8.3 and 8.4
which increased the default_statistics_target from 10 to 100 and its
maximum from 1.000 to 10.000 which makes ANALYZE runs
On Wed, Sep 16, 2009 at 9:39 PM, Martin Lesser ml-osm-...@bettercom.de wrote:
Can anybody confirm this measurement, or even suggest what the reason
might be?
Another pointer: How many VACUUMs does osm2pgsql trigger during import
and filling the own tables?
None, AFAICS from the source.
On Sat, Sep 19, 2009 at 07:12:14PM +0200, Martijn van Oosterhout wrote:
On Wed, Sep 16, 2009 at 9:39 PM, Martin Lesser ml-osm-...@bettercom.de
wrote:
Can anybody confirm this measurement, or even suggest what the reason
might be?
Another pointer: How many VACUUMs does osm2pgsql trigger
Frederik Ramm frede...@remote.org writes:
I did a full (osm2pgsql) planet import on a standard Ubuntu Jaunty
system and it took 1794 minutes. Then I upgraded to Postgres 8.4
(backported from Karmic) plus PostGIS 1.4 (home-built package), and
re-tried the import: 2028 minutes (that's
Hi,
(taking this back onto dev)
Jon Burgess wrote:
It sounds odd that they would be quite so wrong. The osm2pgsql code
performs an ANALYZE as part of the processing.
Something must be wrong there then. The osm2pgsql import with 8.3 has
now completed, again needing 1800 minutes compared to
On 15/09/09 10:42, Frederik Ramm wrote:
Now the two tables create more questions than they answer. Why does the
node table under 8.4 seem to have less entries than under 8.3 when both
have been populated with the same planet file?
An analyse without vacuum only generates an estimate for
On Sun, 2009-09-13 at 19:56 +0200, Frederik Ramm wrote:
Hi,
I did a full (osm2pgsql) planet import on a standard Ubuntu Jaunty
system and it took 1794 minutes. Then I upgraded to Postgres 8.4
(backported from Karmic) plus PostGIS 1.4 (home-built package), and
re-tried the import:
Hi,
Jon Burgess wrote:
Try running the query below and compare the sizes returned for the
tables indexes on the two databases.
Hm, it seems I have overlooked the fact that I also updated osm2pgsql
when I did the update. The old database was created with 0.66. But it
already had integers in
On Sun, 2009-09-13 at 22:45 +0200, Frederik Ramm wrote:
Hi,
Jon Burgess wrote:
Try running the query below and compare the sizes returned for the
tables indexes on the two databases.
Hm, it seems I have overlooked the fact that I also updated osm2pgsql
when I did the update. The old
Hi,
I think I made one more blunder when doing the comparison: I did one
of the imports - the slower one actually! - with the -l flag, the other
one without. (Both were with --slim.) But by now there are too many
variables in the game and it is impossible to tell what is to blame for
the
Frederik Ramm frede...@remote.org writes:
Jon Burgess wrote:
Do you have the _int.sql loaded?
Yes, in both versions; however the _int that comes with PostGIS 1.4
seems to be slightly modified,
Has postgis its own _int.sql? AFAIK _int.sql is part of
postgres-contrib, in the postgis src I
16 matches
Mail list logo
