You don't say what PG version you are on, but just for kicks you may try
using GROUP BY instead of DISTINCT. Yes, the two should perform the
same, but with 8.1 (or maybe 8.0) I had seen situations where GROUP BY
was faster (admittedly this happened with more complex queries). So, try
this:
This seems to be the source of the misestimation. You might
want to try using n WHERE n.nodein NOT IN (SELECT nodeid
FROM templates) instead of n LEFT JOIN templates USING
(nodeid) WHERE templates.nodeid IS NULL and see if it helps.
it helped, the new version of the query takes 2303
Note the DROP INDEX will acquire exclusive lock on the table, so this
might not be the greatest thing to do in a production environment.
In PG 8.2 and up there is a sneakier way to do it that won't acquire
any more lock than the statement-under-test does:
begin;
update pg_index
i have wondered myself. i wouldn't do it through pgAdmin (not sure what
the best test it, but i thought psql from the same machine might be
better--see below). anyway, the funny thing is that if you concatenate
them the time drops:
~% time psql -dXXX -hYYY -UZZZ -cselect consumer_id from consumer
On Fri, 2006-08-25 at 21:23 +0530, soni de wrote:
Hello,
I want to ask, Is there any way to insert records from XML
file to the postgres database?
Try the contrib/xml2 module.
Alas, that module will not help you much with the insertion of records.
It is more about querying XML that
These stats are not stored in tables, only in memory and saved to a
special file on disk to be able to preserve it across server
stop/start.
But pg_dump does not make the slightest attempt to save it.
Also, you can't save it yourself -- while you could save the values it
returns on
Without having looked at this in detail my first suggestion would be to
do away with those date_part indices. I have found that indexes with few
distinct values usually hurt more then help and the PG optimizer is not
always smart enough to ignore them and the BitmapAnd and scan for dates
seem like
This did not have any takers in pgsql-general. Maybe
performance-oriented folks can shed light? The basic question is if
there is a way to preserve stats during pg_restore?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of George Pavlov
Sent: Monday
I am looking for some general guidelines on what is the performance
overhead of enabling point-in-time recovery (archive_command config) on
an 8.1 database. Obviously it will depend on a multitude of factors, but
some broad-brush statements and/or anecdotal evidence will suffice.
Should one worry
