On Sat, Jun 7, 2008 at 5:16 PM, Viktor Rosenfeld
[EMAIL PROTECTED] wrote:
Hi Scott,
Am 07.06.2008 um 16:53 schrieb Scott Marlowe:
I'm experimenting with different indexes to speed up my queries and I was
wondering if it is possible to temporarily deactivate an index, so it
won't
be
On Sat, Jun 7, 2008 at 8:07 PM, Jeremy Harris [EMAIL PROTECTED] wrote:
Gregory Stark wrote:
REINDEX scans the table
precisely once and sorts it.
For the bloat, as opposed to corruption, case -
what information is needed from the table that
is not in the old index? Why would a
Hello,
I have the same issue as this poster with libpq.so.4:
http://www.nabble.com/8.3.0-upgrade-td16093803.html
In short, I've upgraded to 8.3.1 from 8.1 on RHEL 4 (with some CentOS
packages). I have apps with dependencies of libpq.so.4 but this is no
longer available. 8.3.1 provides
On Sun, Jun 8, 2008 at 1:34 AM, Scott Marlowe [EMAIL PROTECTED] wrote:
On Sat, Jun 7, 2008 at 5:16 PM, Viktor Rosenfeld
[EMAIL PROTECTED] wrote:
Try this:
begin;
drop indexname;
explain analyze select ...;
rollback;
That works, but I'm still looking for another way to deactivate the
On Sun, Jun 8, 2008 at 7:55 AM, Jaime Casanova [EMAIL PROTECTED] wrote:
On Sun, Jun 8, 2008 at 1:34 AM, Scott Marlowe [EMAIL PROTECTED] wrote:
On Sat, Jun 7, 2008 at 5:16 PM, Viktor Rosenfeld
[EMAIL PROTECTED] wrote:
Try this:
begin;
drop indexname;
explain analyze select ...;
rollback;
Charles F. Munat wrote:
Thanks, but the join clause is there, it's just buried in the subqueries.
If there is a problem, it is probably that the loop never ends.
Or it could be that the answer is exponential, and I just have too many
rows in the source table and too deep a graph.
I figured
Viktor Rosenfeld [EMAIL PROTECTED] writes:
That works, but I'm still looking for another way to deactivate the
index. The reason being, that my query load is randomly generated by
a Java program and I don't want to go and change the SQL compiler.
Well, you're going to have to change
Oliver Kohll [EMAIL PROTECTED] writes:
What I've thought of trying so far is
1) creating a symlink called libpq.so.4 towards libpq.so.5 - slightly
dangerous due to possible API changes?
Worth trying. According to the CVS logs
On Sun, Jun 8, 2008 at 11:45 AM, Tom Lane [EMAIL PROTECTED] wrote:
Viktor Rosenfeld [EMAIL PROTECTED] writes:
That works, but I'm still looking for another way to deactivate the
index. The reason being, that my query load is randomly generated by
a Java program and I don't want to go and
Jaime Casanova escribió:
if i mark the index not ready (using pg_index.indisvalid or
pg_index.indisready depending on version), will the index be updated
if in another transaction i make an insert?
Yes (in fact that's the whole point of having an index marked not
valid/ready).
--
Alvaro
Oliver Kohll wrote:
I have the same issue as this poster with libpq.so.4:
http://www.nabble.com/8.3.0-upgrade-td16093803.html
In short, I've upgraded to 8.3.1 from 8.1 on RHEL 4 (with
some CentOS packages). I have apps with dependencies of
libpq.so.4 but this is no longer available. 8.3.1
Am Sunday, 8. June 2008 schrieb Albe Laurenz:
In short, I've upgraded to 8.3.1 from 8.1 on RHEL 4 (with
some CentOS packages). I have apps with dependencies of
libpq.so.4 but this is no longer available. 8.3.1 provides
libpq.so.5 and the compat-libs provide libpq.so.3.
Strange; does
I have a query that takes 2 sec if I run it from a freshly restored dump.
If I run a full vacuum on the database it then takes 30 seconds.
What do the two plans look like? Can you post the explains?
-Nathan
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make
Hi,
On Sun, 2008-06-08 at 11:55 +0100, Oliver Kohll wrote:
snip
3) building a custom compat package - I don't know how to do this
though.
These are probably my packages from http://yum.pgsqlrpms.org , and I
thought I already fixed this issue -- I'll check.
Anyway,
Peter Eisentraut [EMAIL PROTECTED] writes:
A workable fix, at least from the point of view of a Debian developer, is to
put the soname number into the package name (libpq3, libpq4, libpq5, etc.),
thus making them unique and coinstallable for all times.
FWIW, the package names Red Hat has
Thanks all, option 2 seems to work for me, just wanted to be sure I
wasn't asking for crashes.
Oliver Kohll
On 8 Jun 2008, at 18:01, Tom Lane wrote:
Oliver Kohll [EMAIL PROTECTED] writes:
What I've thought of trying so far is
1) creating a symlink called libpq.so.4 towards libpq.so.5 -
sorry, forgot to cc: to the group..To: Alvaro Herrera
[EMAIL PROTECTED]
not as far as I can tell... I have log_destination='stderr'. unless csv
logging is enabled in another location?
Since I disabled the following line:
shared_preload_libraries = '$libdir/plugins/plugin_debugger.dll'
and
17 matches
Mail list logo
