Well, I'll be dipped! More below;
Tom Lane <[EMAIL PROTECTED]> writes:
> On further analysis, it seems the problem is dependent on the exact
> ordering of the inputs to the qsort function. So not only do you need
> maintenance_work_mem to be large enough that the code will try to use
> qsort, b
Jerry Sievers <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> What I still don't understand though is why you see it
>> in 8.1 and not 8.0 ... the src/port/qsort.c code didn't change at all
>> between those versions. Maybe 8.0 isn't taking the qsort code path,
>> perhaps beca
Hi Tom;
Tom Lane <[EMAIL PROTECTED]> writes:
> Jerry Sievers <[EMAIL PROTECTED]> writes:
> > Platform is Solaris 2.9
>
> I think this might be the key...
>
> I can reproduce an unreasonably long runtime if I use src/port/qsort.c
> (as we do on Solaris), but not with glibc's version of qsort. I
Jerry Sievers <[EMAIL PROTECTED]> writes:
> Platform is Solaris 2.9
I think this might be the key...
I can reproduce an unreasonably long runtime if I use src/port/qsort.c
(as we do on Solaris), but not with glibc's version of qsort. I think
you are seeing the poor-choice-of-qsort-pivots problem
Hi all,
I am runnning PostgreSQL 8.3.1 on FreeBSD 6.0.
There are about 30 heavy readed / updated databases and very often is
occurred situation that there accumulate processes and waiting for each
other, for example:
when server starts, there are a few processes:
ps ax |grep postgres
50120
Jerry Sievers <[EMAIL PROTECTED]> writes:
> Any idea if there was a signal that this might have responded to shy
> of -9?
SIGQUIT might work.
Also, I'd be interested to take a look if you can send me a dump of just
the index key column data. (COPY with a column list can do that.)
Hi Tom, thanks for responding on this. More below;
Tom Lane <[EMAIL PROTECTED]> writes:
> Jerry Sievers <[EMAIL PROTECTED]> writes:
> > What happened was that for a couple minutes the CPU load would
> > steadily increase and disk activity decrease at the same time. Before
> > long, one CPU is 10
Jerry Sievers <[EMAIL PROTECTED]> writes:
> What happened was that for a couple minutes the CPU load would
> steadily increase and disk activity decrease at the same time. Before
> long, one CPU is 100% busy and we let this continue for 2 hours, a
> 100x longer than this index usually takes to bui
This message was cancelled from within Mozilla.
---(end of broadcast)---
TIP 6: explain analyze is your friend
test
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Hello list; We stumbled on a maintenance_work_mem related problem with
index builds.
Recently imported a good sized DB into a new 8.1.3 install on platform
SunOS 5.9. The DB consists of some 400 tables and about twice as many
indexes.
The Upgrade went very smoothly until we hit an index build ov
Dear Oleg,
Thanks Oleg
> use en_US.UTF-8
it works as I did
test_db=# update pg_ts_cfg set locale = 'en_US.UTF-8';
So to summarize
if you recive a error like
ERROR: could not find tsearch config by locale INSERT INTO mm_message (
Then log into the server and run the query
test_db=# show all;
Read
http://www.sai.msu.su/~megera/oddmuse/index.cgi/Tsearch_V2_Notes
and provide us more info about your setup.
Check 'show all' output for locale setup
Oleg
On Thu, 16 Mar 2006, Vishal Kashyap wrote:
Hi all ,
tsearch2 is giving me jitters for days now and after full
investigation I
Hi all ,
tsearch2 is giving me jitters for days now and after full
investigation I am writting into list.
The error is
ERROR: could not find tsearch config by locale INSERT INTO mm_message (
The investigation is
my_db=# select * from pg_ts_cfg;
ts_name | prs_name |locale
-
14 matches
Mail list logo
