On 10-12-16 11:27 AM, Tom Lane wrote:
Eric Comeau <mailto:ecom...@signiant.com>
writes:
> Is there a way force the db to re-evaluate its execution plan for a FK
> without bouncing the DB?
> PostgreSQL 8.1.17
Yo
On 10-12-16 11:27 AM, Tom Lane wrote:
Eric Comeau writes:
Is there a way force the db to re-evaluate its execution plan for a FK
without bouncing the DB?
PostgreSQL 8.1.17
You don't need to bounce the whole DB, but you will need to start fresh
sessions. We didn't add
On 10-12-16 07:34 AM, Jayadevan M wrote:
Hello,
Is there a way force the db to re-evaluate its execution plan for a FK
without bouncing the DB?
PostgreSQL 8.1.17
In our latest release our developers have implemented some new foreign
keys but forgot to create indexes on these keys.
The prob
Is there a way force the db to re-evaluate its execution plan for a FK
without bouncing the DB?
PostgreSQL 8.1.17
In our latest release our developers have implemented some new foreign
keys but forgot to create indexes on these keys.
The problem surfaced at one of our client installs wher
On 10-11-17 12:28 PM, Merlin Moncure wrote:
On Wed, Nov 17, 2010 at 9:26 AM, Eric Comeau
<mailto:ecom...@signiant.com> wrote:
> This is not directly a PostgreSQL performance question but I'm hoping
some
> of the chaps that build high IO PostgreSQ
This is not directly a PostgreSQL performance question but I'm hoping
some of the chaps that build high IO PostgreSQL servers on here can help.
We build file transfer acceleration s/w (and use PostgreSQL as our
database) but we need to build a test server that can handle a sustained
write thro
On 10-10-18 11:02 AM, Tom Lane wrote:
Mladen Gogala writes:
Tom Lane wrote:
My guess would be overstressed disk subsystem. A COMMIT doesn't require
much except fsync'ing the commit WAL record down to disk ...
Doesn't the "commit" statement also release all the locks held by the
transaction
We currently have
log_min_duration_statement = 5000
and are seeing statements like the following logged
2010-10-16 05:55:52 EDT [6334]: [1-1] LOG: duration: 5572.517 ms
statement: EXECUTE [PREPARE: COMMIT]
2010-10-16 06:06:24 EDT [26856]: [1-1] LOG: duration: 5617.866 ms
statement: EXE
>>> It really has very little impact. It only affects index scans, and
>>> even then only if effective_cache_size is less than the size of the
>> table.
>>>
>>> Essentially, when this kicks in, it models the effect that if you are
>>> index scanning a table much larger than the size of your cache,
