Robert Haas wrote:
On Mon, Mar 23, 2009 at 1:08 PM, Anne Rosset wrote:
enable_nestloop = off
That may be the source of your problem. Generally setting enable_* to
off is a debugging tool, not something you ever want to do in
production.
...Robert
Thanks Robert. It seems to have
On Mon, Mar 23, 2009 at 1:08 PM, Anne Rosset wrote:
> enable_nestloop = off
That may be the source of your problem. Generally setting enable_* to
off is a debugging tool, not something you ever want to do in
production.
...Robert
--
Sent via pgsql-performance mailing list (pgsql-performance@p
Tom Lane wrote:
Robert Haas writes:
On Fri, Mar 20, 2009 at 1:16 PM, Anne Rosset wrote:
The db version is 8.2.4
Something is wrong here. How can setting enable_seqscan to off result
in a plan with a far lower estimated cost than the original plan?
Planner bug no
On Fri, Mar 20, 2009 at 4:29 PM, Anne Rosset wrote:
> Alvaro Herrera wrote:
>> Robert Haas escribió:
>>> Something is wrong here. How can setting enable_seqscan to off result
>>> in a plan with a far lower estimated cost than the original plan? If
>>> the planner thought the non-seq-scan plan is
Robert Haas writes:
> On Fri, Mar 20, 2009 at 1:16 PM, Anne Rosset wrote:
>> The db version is 8.2.4
> Something is wrong here. How can setting enable_seqscan to off result
> in a plan with a far lower estimated cost than the original plan?
Planner bug no doubt ... given how old the PG release
Alvaro Herrera wrote:
Robert Haas escribió:
Something is wrong here. How can setting enable_seqscan to off result
in a plan with a far lower estimated cost than the original plan? If
the planner thought the non-seq-scan plan is cheaper, it would have
picked that one to begin with.
Robert Haas escribió:
> Something is wrong here. How can setting enable_seqscan to off result
> in a plan with a far lower estimated cost than the original plan? If
> the planner thought the non-seq-scan plan is cheaper, it would have
> picked that one to begin with.
GEQO? Anne, what's geqo_th
On Fri, Mar 20, 2009 at 1:16 PM, Anne Rosset wrote:
> Richard Huxton wrote:
>> Anne Rosset wrote:
>>> EXPLAIN ANALYZE
>>> SELECT
>>> audit_change.id AS id,
>>> audit_change.audit_entry_id AS auditEntryId,
>>> audit_entry.object_id AS objectId,
>>> audit_change.property_name
Richard Huxton wrote:
Anne Rosset wrote:
EXPLAIN ANALYZE
SELECT
audit_change.id AS id,
audit_change.audit_entry_id AS auditEntryId,
audit_entry.object_id AS objectId,
audit_change.property_name AS propertyName,
audit_change.property_type AS propertyType,
audit_chang
Richard Huxton writes:
>> Hash Join (cost=8.79..253664.55 rows=4 width=136) (actual
>> time=4612.674..6683.158 rows=4 loops=1)
>> Hash Cond: ((audit_change.audit_entry_id)::text = (audit_entry.id)::text)
>> -> Seq Scan on audit_change (cost=0.00..225212.52 rows=7584852
>> width=123) (actual tim
Anne Rosset wrote:
> EXPLAIN ANALYZE
> SELECT
> audit_change.id AS id,
> audit_change.audit_entry_id AS auditEntryId,
> audit_entry.object_id AS objectId,
> audit_change.property_name AS propertyName,
> audit_change.property_type AS propertyType,
> audit_change.old_v
Hi,
We have the following 2 tables:
\d audit_change
Table "public.audit_change"
Column | Type | Modifiers
++---
id | character varying(32) | not null
audit_entry_id | character varying(32) |
...
In
12 matches
Mail list logo
