Have you tried an analyze after 1,000 or so inserts? Also, you should
be able to disable sequence scans for the duration of the connection
using SET enable_seqscan=false.
-Zeki
Brian O'Reilly wrote:
The following bug has been logged online:
Bug reference: 1552
Logged by: Brian O'
Josh Berkus wrote:
Brian,
They PGSQL-PERFORMANCE list is really the appropriate place for performance
issues like yours. Subscribe?
http://www.postgresql.org/community/lists
Yes, I will subscribe to the performance list, but strictly speaking the
behaviour described should be considered a bu
Simon Riggs <[EMAIL PROTECTED]> writes:
> I think we should spawn a TODO item from this:
> * Coerce FK lookups to always use an available index
No, we aren't doing that.
The correct TODO item is "Replan cached plans when table size has
changed a lot" which of course depends on having a framework
On Wed, 2005-03-23 at 14:22 -0500, Keith Browne wrote:
> Simon Riggs wrote:
>
> > The EXPLAINs you've enclosed are for SELECTs, yet your bug report
> > describes INSERTs as being the things that are slow.
> > [You may find better performance from using COPY]
> We're starting with an empty databas
I wrote:
> ... Maybe we could
> put in a hack that detects whether a table has yet been vacuumed, and
> sets 10/1000 as the minimum stats --- not fixed values, but minimum
> values that can be overridden when the table is actually larger ---
> until it has been vacuumed.
For lack of any better s
On 2005-03-23, Tom Lane <[EMAIL PROTECTED]> wrote:
> No, it wouldn't, because by the time you do the first FK trigger you'd
> have one row/one page in the referenced table, so it'd still look like a
> seqscan situation to the planner. The only way we could make that work
> is to effectively disabl
Keith Browne <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I'm still looking for an example that demonstrates why this is a common
>> problem that we need to worry about.
> We're filling pairs of tables with rows having nearly a one-to-one
> mapping; very rarely, the second table will have mul
On 2005-03-23, Tom Lane <[EMAIL PROTECTED]> wrote:
> Andrew - Supernews <[EMAIL PROTECTED]> writes:
>> Changing the order so that the referenced table is fully populated, or at
>> least populated with more than a handful of pages of rows, before doing
>> _any_ insert on a referencing table in the s
Tom Lane wrote:
I'm still looking for an example that demonstrates why this is a common
problem that we need to worry about. ISTM that if an FK reference is
hit when there are still zero entries in the referenced table, that
insertion will fail anyway, and so people wouldn't try to load data in
su
Andrew - Supernews <[EMAIL PROTECTED]> writes:
> Changing the order so that the referenced table is fully populated, or at
> least populated with more than a handful of pages of rows, before doing
> _any_ insert on a referencing table in the same session will avoid the
> misplan of the FK trigger q
On 2005-03-23, Keith Browne <[EMAIL PROTECTED]> wrote:
> One other thing which puzzled me: as a test, I tried modifying our
> script to spit out raw SQL statements instead of connecting to the
> database and performing the inserts itself. Normally, our script
> populates two tables in one pass,
Simon Riggs wrote:
The EXPLAINs you've enclosed are for SELECTs, yet your bug report
describes INSERTs as being the things that are slow.
[You may find better performance from using COPY]
Simon,
Brian and I are working together on this problem.
We're starting with an empty database, creating four t
On Fri, 2005-03-18 at 23:21 +, Brian O'Reilly wrote:
> The following bug has been logged online:
>
> Bug reference: 1552
> Logged by: Brian O'Reilly
> Email address: [EMAIL PROTECTED]
> PostgreSQL version: 8.0.1
> Operating system: Linux 2.6.11
> Description:massiv
They PGSQL-PERFORMANCE list is really the appropriate place for
performance issues like yours. Subscribe?
Josh,
Brian and I are trying to put upwards of 80-90,000 rows into a table.
When we run on PostgreSQL 7.4, this takes about five minutes. On
comparable hardware, running PostgreSQL 8.0.1, it
Josh Berkus writes:
> I don't think your experience on this one query is descriptive of PostgreSQL
> in general. What I'm saying is that you most likely have a tuning problem,
> not a bug.
It might be a bug (or at least an unhelpful behavior) but the given case
didn't prove a thing. I'm st
Brian,
> Yes, I will subscribe to the performance list, but strictly speaking the
> behaviour described should be considered a bug. The assumptions made in
> deciding what the query optimisations will be seem all skewed, and the
> end result is that the system
> isn't useful in very common cases.
Brian,
They PGSQL-PERFORMANCE list is really the appropriate place for performance
issues like yours. Subscribe?
http://www.postgresql.org/community/lists
--
--Josh
Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
TI
17 matches
Mail list logo
