Re: pgbench create index anomoly - Mailing list pgsql-hackers

From Jim C. Nasby
Subject Re: pgbench create index anomoly
Date
Msg-id 20060522200131.GQ64371@pervasive.com
Whole thread Raw
In response to Re: pgbench create index anomoly  (Simon Riggs <simon@2ndquadrant.com>)
List pgsql-hackers
On Mon, May 22, 2006 at 08:54:20PM +0100, Simon Riggs wrote:
> On Mon, 2006-05-22 at 14:01 -0500, Jim C. Nasby wrote:
> > While setting up for the compressed sort testing...
> > 
> > NOTICE:  ALTER TABLE / ADD PRIMARY KEY will create implicit index "accounts_pkey" for table "accounts"
> > LOG:  begin index sort: unique = t, workMem = 16384, randomAccess = f
> > LOG:  begin index sort: unique = t, workMem = 16384, randomAccess = f
> 
> If you set log_line prefix to something that allows us to differentiate
> those lines we might be able to identify them. The second line could

Such as?

There's nothing else running on this instance, so everything you see is
because of pgbench. And it did that for every ALTER TABLE. I'm assuming
this is actually a backend issue of some kind and not pgbench, since I
don't find the string 'work' anywhere in it's source.

> well be from a heap sort executed on a different backend; 1024 is the
> default work_mem. Some psql commands use hidden SQL with an ORDER BY, so
> you can sometimes be a little confused from the log.
> 
> Happy to look into it if there really is something wierd going on.
-- 
Jim C. Nasby, Sr. Engineering Consultant      jnasby@pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: pgbench create index anomoly
Next
From: imacat
Date:
Subject: Re: Compiling PL/Perl and Pl/Python on x86_64