Re: [GENERAL] Vacuum time degrading
On 3/2/05 3:51 PM, "Tom Lane" <[EMAIL PROTECTED]> wrote: > I was going to suggest > REINDEXing those indexes to see if that cuts the vacuum time at all. The problem with that is it takes a very long time. I've got a couple of things to try yet on the kswapd problem. If that doesn't work, maybe I can rebuild one of the indexes and see how much that one improves. I wasn't aware that the indexes were scanned non-sequentially. The under one hour time was probably shortly after a full reload. Any chance of change that behavior to scan in physical storage order? The index from the largest table that has: CPU 216.15s/18.13u sec elapsed 2110.84 sec. is inserted in sequential order. The index CPU 518.88s/25.17u sec elapsed 10825.33 sec. has records inserted in essentially a random order, and is also something like twice as large (key size). We're going to try to test the 2.4.29 kernel tomorrow. Wes ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [GENERAL] Cursors and Transactions, why?
On 4/6/04 11:09 PM, "Tom Lane" <[EMAIL PROTECTED]> wrote: > What "out of memory thing"? The tuplestore code is perfectly capable of > spilling to disk --- in fact the usual performance gripe against it has > to do with spilling too soon, because sort_mem is set too small. I tried doing a mass update of all rows with a single SQL statement in psql and after it ran for many hours, I got 'out of memory'. I didn't try that using C and WITH HOLD. I assumed it ran out of swap space, but was sleeping at the time. Wes ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[GENERAL] thread_test.c problems
When I try to run thread_test.c from the CVS tip, it hangs in an infinite CPU loop on both linux (RedHat AS 3.0, gcc 3.2.3) and Mac OS X 10.3.3 (gcc 3.3). I've also tried down to gcc 2.96 on Mac OS X. If I compile it with -g instead of -O2 on linux, it runs to completion and gives me: Add this to your template/$port file: STRERROR_THREADSAFE=yes GETPWUID_THREADSAFE=no GETHOSTBYNAME_THREADSAFE=no On Mac OS X, it gives me: Add this to your template/$port file: STRERROR_THREADSAFE=yes GETPWUID_THREADSAFE=yes GETHOSTBYNAME_THREADSAFE=yes If I modify the two while loops while (errno2_set == 0) while (errno1_set == 0) To execute a 'print' statement or a 'time(NULL)' instead of a null loop, then it runs to completion with -O2. If I run the 7.4.2 version of thread_test.c, for both platforms I get: Add this to your template/$port file: NEED_REENTRANT_FUNCS=yes On linux, the make run is: ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] Compound keys and foreign constraints
> Is there an index on message_recipients(Message_Key)? Yes. > How many rows satisfy > > SELECT * FROM messages WHERE Message_Date BETWEEN ... AND ... ? db=> select count(*) from messages where message_date between '29-Mar-04' and '31-Mar-04 23:59:59'; count 737873 (1 row) Other cases where the number of records are smaller result in the same plan. Even a simple query like select count(*) from messages where (message_key=1234) AND message_date (between '29-Mar-04' and '31-Mar-04 23:59:59') Will use only the message_key index if define. I've tried every query I can think of and it won't use the compound index as long as the message_key index is defined - which I need for the foreign constraints. > And what are your settings for random_page_cost, effective_cache_size, > and sort_mem? Default - I have not changed those. I did bump up some postgresql.conf memory settings, but haven't touched any of the cost parameters. Wes ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [GENERAL] 7.4.2 on Solaris 9 - Error
On 3/25/04 4:13 PM, "Bruce Momjian" <[EMAIL PROTECTED]> wrote: > Are you sure your change is correct? We just added > "-D_POSIX_PTHREAD_SEMANTICS" in post 7.4.2, and the submitters did not > mention any problems with the -pthread line for gcc. > > I just tried it on Sourceforge's Solaris 9 and I see: > > bash-2.05$ gcc -pthread > gcc: unrecognized option `-pthread' > gcc: no input files > > which seems to indicate you are right. I am kind of surprised. Some > platforms to take -pthread, some -lpthread, so I am pretty sure it was > specified by the original Solaris guy. Don't know... I assume it was just a typo that wouldn't show up if you were using SUNWSPRO compiler instead of GCC. > OK, new template/solaris version applied to 7.4.X and head: [snip] > THREAD_SUPPORT=yes > NEED_REENTRANT_FUNCS=yes# 5.6 2003-09-13 > THREAD_CPPFLAGS="-D_POSIX_PTHREAD_SEMANTICS" > if test "$GCC" != yes > thenTHREAD_CPPFLAGS="$THREAD_CPPFLAGS -mt" > fi > THREAD_LIBS="-lpthread" Shouldn't that be THREAD_CPPFLAGS="-D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS" According to Jan, -D_REENTRANT must also be specified for libpq to be built correctly. Why isn't -D_THREAD_SAFE required also? Wes ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
