> > One thing I did notice that in a 250k insert transaction the insert
time
> > grows with #recs inserted. Time to insert first 50k recs is about
27
> > sec and last 50 k recs is 77 sec. I also confimed that size of
table is
> > not playing a role here.
> >
> > Marc, can you do select timeofday(
On Tuesday 06 September 2005 19:11, Merlin Moncure wrote:
> > This makes me wonder if we are looking in the wrong place. Maybe the
> > problem is coming from psql? More results to follow.
>
> problem is not coming from psql.
>
> One thing I did notice that in a 250k insert transaction the insert
> On Tuesday 06 September 2005 19:11, Merlin Moncure wrote:
> Here's the timeofday ... i'll do the gprof as soon as I can.
> Every 5 rows...
>
> Wed Sep 07 13:58:13.860378 2005 CEST
> Wed Sep 07 13:58:20.926983 2005 CEST
> Wed Sep 07 13:58:27.928385 2005 CEST
> Wed Sep 07 13:58:35.472813 2005
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> ok, I've been in crunching profile profile graphs, and so far have been
> only been able to draw following conclusions.
> For bulk, 'in-transaction' insert:
> 1. win32 is slower than linux. win32 time for each insert grows with #
> inserts in xact, l
Hello,
I'm a newbie in postgresql, I've installed it on a Windows XP machine
( I can't use linux, it's a company machine ), I'm courious why this
query takes so long
SELECT "Rut Cliente"
FROM "Internet_Abril"
WHERE "Rut Cliente" NOT IN ((SELECT "Rut Cliente" FROM
"Internet_Enero") UNION (SELECT
On Wed, Sep 07, 2005 at 12:22:27PM -0400, Christian Compagnon wrote:
> I'm a newbie in postgresql, I've installed it on a Windows XP machine
> ( I can't use linux, it's a company machine ), I'm courious why this
> query takes so long
It sounds like you've set work_mem too low; increasing it might
PG is creating the union of January, February and March tables first
and that doesn't have an index on it. If you're going to do many
queries using the union of those three tables, you might want to place
their contents into one table and create an index on it.
Otherwise, try something like this:
On Wed, 7 Sep 2005, Meetesh Karia wrote:
> PG is creating the union of January, February and March tables first and
> that doesn't have an index on it. If you're going to do many queries using
> the union of those three tables, you might want to place their contents into
> one table and create an
"Steinar H. Gunderson" <[EMAIL PROTECTED]> writes:
> (I'm not sure how optimized UNION inside an IN/NOT IN is.)
NOT IN is pretty nonoptimal, period. It'd help a lot to boost work_mem
to the point where the planner figures it can use a hashtable (look for
EXPLAIN to say "hashed subplan" rather tha
On Wed, Sep 07, 2005 at 11:07:04AM +0800, Christopher Kings-Lynne wrote:
> >Unfortunately there's no very simple way to determine which FK is the
> >problem. (In 8.1 it'll be possible to do that with EXPLAIN ANALYZE,
> >but in existing releases EXPLAIN doesn't break out the time spent in
> >each t
10 matches
Mail list logo
