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 end.
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 argument
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 row
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.
: 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
[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 see
]
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 on varchar(2) with value being 'O', 'N' or null;
I wonder if it's
[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
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 already do
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 (both 7.3.4 and 7.4b)
I'm on the FR language (I'll re-initdb whith
[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
[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
] 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. 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
[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
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.
So I reinitDB with LANG=FR and used LANG=C to psql -f xxx.sql template1
15 matches
Mail list logo
