On Mon, 8 Sep 2003 11:31:05 +0200, "Zeugswetter Andreas SB SD"
<[EMAIL PROTECTED]> wrote:
>> As Tom mentioned, we might not want to keep the tid's in order after the
>> index is created because he wants the most recent tid's first, so the
>> expired ones migrate to the end.
>
>But on average this a
> > I don't think so, because the patch does nothing to keep the sort
> > order once the index is initially created.
>
> As Tom mentioned, we might not want to keep the tid's in order after the
> index is created because he wants the most recent tid's first, so the
> expired ones migrate to the e
Manfred Koizar wrote:
> On Sun, 7 Sep 2003 11:43:42 -0400 (EDT), Bruce Momjian
> <[EMAIL PROTECTED]> wrote:
> >I assume this completes this TODO:
> >
> > * Order duplicate index entries by tid for faster heap lookups
>
> I don't think so, because the patch does nothing to keep the sort
> order
On Sun, 7 Sep 2003 11:43:42 -0400 (EDT), Bruce Momjian
<[EMAIL PROTECTED]> wrote:
>I assume this completes this TODO:
>
> * Order duplicate index entries by tid for faster heap lookups
I don't think so, because the patch does nothing to keep the sort
order once the index is initially created
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I assume this completes this TODO:
> * Order duplicate index entries by tid for faster heap lookups
I don't know why that TODO entry exists, but I think the idea is
counterproductive. The existing btree code will tend to put newer
versions of a ro
I assume this completes this TODO:
* Order duplicate index entries by tid for faster heap lookups
and you will submit it for 7.5? If you want to post it now, I can get
it into the 7.5 queue so we don't forget it.
-
On Mon, 01 Sep 2003 08:46:09 -0400, Tom Lane <[EMAIL PROTECTED]>
wrote:
>[EMAIL PROTECTED] writes:
>> it took 69 minutes to finish, 75% of this time was devoted to create 2
>> indexes on varchar(2) with value being 'O', 'N' or null;
>
>I still say it's either strcoll or qsort's fault.
If qsort is
[EMAIL PROTECTED] writes:
> I've made some tests with your qsort and it DEFINITIVLY help
> ~3 mn instead of 69.
> However this is for 7.3.4 I've got no probs with 7.4b.
> Did something change in btree creation?
Hmm, I wouldn't have thought so, but perhaps we did change something
that would affect
lt;[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: pgsql-hackers list <[EMAIL PROTECTED]>
> Subject: Re: [HACKERS] Index creation takes for ever
>
> [EMAIL PROTECTED] writes:
> > it took 69 minutes to finish, 75% of this time was devoted to create 2
> > indexes
[EMAIL PROTECTED] writes:
> it took 69 minutes to finish, 75% of this time was devoted to create 2
> indexes on varchar(2) with value being 'O', 'N' or null;
> I wonder if it's a configuration matter.
I still say it's either strcoll or qsort's fault. Try swapping in our
own version of qsort to se
tion took 100% of 1 CPU.
Regards
On Thu, 28 Aug 2003, Tom Lane wrote:
> Date: Thu, 28 Aug 2003 10:13:21 -0400
> From: Tom Lane <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: pgsql-hackers list <[EMAIL PROTECTED]>
> Subject: Re: [HACKERS] Index creation takes fo
omjian <[EMAIL PROTECTED]>
> To: Tom Lane <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED], pgsql-hackers list <[EMAIL PROTECTED]>
> Subject: Re: [HACKERS] Index creation takes for ever
>
> Tom Lane wrote:
> > [EMAIL PROTECTED] writes:
> > > This is on unixware 7
Tom Lane wrote:
> [EMAIL PROTECTED] writes:
> > This is on unixware 7 (both 7.3.4 and 7.4b)
>
> > I'm on the FR language (I'll re-initdb whith lang=C to see what happens)
>
> Okay. If you find it's still slow in C locale, the next thing to try
> would be forcing use of our own qsort, as we alrea
-0400
> From: Tom Lane <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: pgsql-hackers list <[EMAIL PROTECTED]>
> Subject: Re: [HACKERS] Index creation takes for ever
>
> [EMAIL PROTECTED] writes:
> > I've reinitdb (on 7.4b) with LANG=C and it worked.
>
[EMAIL PROTECTED] writes:
> I've reinitdb (on 7.4b) with LANG=C and it worked.
> So I reinitDB with LANG=FR and used LANG=C to psql -f xxx.sql template1 to
> recreate the db and it worked too...
That's weird. I don't understand why an initdb in the same locale would
make the problem go away.
> I
-hackers list <[EMAIL PROTECTED]>
> Subject: Re: [HACKERS] Index creation takes for ever
>
> [EMAIL PROTECTED] writes:
> > This is on unixware 7 (both 7.3.4 and 7.4b)
>
> > I'm on the FR language (I'll re-initdb whith lang=C to see what happens)
>
> Okay.
[EMAIL PROTECTED] writes:
> This is on unixware 7 (both 7.3.4 and 7.4b)
> I'm on the FR language (I'll re-initdb whith lang=C to see what happens)
Okay. If you find it's still slow in C locale, the next thing to try
would be forcing use of our own qsort, as we already do for Solaris.
You'd need
ll process took only 5 Min.
On Thu, 28 Aug 2003, Tom Lane wrote:
> Date: Thu, 28 Aug 2003 10:13:21 -0400
> From: Tom Lane <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: pgsql-hackers list <[EMAIL PROTECTED]>
> Subject: Re: [HACKERS] Index creation takes for ever
>
&
[EMAIL PROTECTED] writes:
> I've then pg_dump'ed the database and recreate an other both on 7.3.4 and
> 7.4b
> Both are still running after more than 30 minutes of CPU (100% cpu taken)
> creating the levt_lu_ligne_evt_key.
That's hard to believe. I get
regression=# SELECT levt_lu,count(*) from
19 matches
Mail list logo
