Andrew,
> The Packer Solaris database book (Packer, Allan N., _Configuring &
> Tuning Databases on the Solaris Platform_. Palo Alto: Sun
> Microsystems P, 2002. ISBN 0-13-083417-3) does suggest mounting the
> filesystems with forcedirectio; I dimly recall using this for the wal
> partition on on
On Wed, Mar 23, 2005 at 09:32:07AM -0800, Tom Arthurs wrote:
> found that high context switching seems to be more a symptom,
Yes, that's a good point. It usually _is_ a symptom; but it might be
a symptom that you've got an expensive query, and Solaris's foot-gun
approach to handling such cases is
On Wed, Mar 23, 2005 at 11:16:29AM -0600, Brandon Metcalf wrote:
>
> We moved from an HP-UX 10.20 box where the pgsql installation and data
> were on a vxfs fileystem.
My best guess, then, is that ufs tuning really is your issue. We
always used vxfs for our Sun database servers (which was a nigh
On the context switching issue, we've found that this setting in /etc/system
helps:
set rechoose_interval=30
this sets the minimum time that a process is eligible to be switched to another
cpu. (the default is 3).
You can monitor context switching with the cs column in vmstat. We've found
that
a == [EMAIL PROTECTED] writes:
a> On Tue, Mar 22, 2005 at 03:23:18PM -0600, Brandon Metcalf wrote:
a> > s> What are you using to measure
a> > s> performance?
a> >
a> > Nothing too scientific other than the fact that since we have moved
a> > the DB, we consistenly see a large number of post
On Tue, Mar 22, 2005 at 03:23:18PM -0600, Brandon Metcalf wrote:
> s> What are you using to measure
> s> performance?
>
> Nothing too scientific other than the fact that since we have moved
> the DB, we consistenly see a large number of postmater processes
> (close to 100) where before we did no
"Tambet Matiisen" <[EMAIL PROTECTED]> writes:
> I observed slowdowns when I declared SQL function as strict. There were
> no slowdowns, when I implmented the same function in plpgsql, in fact it
> got faster with strict, if parameters where NULL. Could it be
> side-effect of SQL function inlining?
Dawid Kuroczko wrote:
On Wed, 23 Mar 2005 12:11:56 +0800, Michael Ryan S. Puncia
<[EMAIL PROTECTED]> wrote:
I have an experience using LIKE in a VARCHAR column and select statement
suffers a lot so I decided to go back in CHAR
According to the PostgreSQL's documentation:
Tip: There are no per
I observed slowdowns when I declared SQL function as strict. There were
no slowdowns, when I implmented the same function in plpgsql, in fact it
got faster with strict, if parameters where NULL. Could it be
side-effect of SQL function inlining? Is there CASE added around the
function to not calcula
On Wed, 23 Mar 2005, Rick Jansen wrote:
Oleg Bartunov wrote:
On Tue, 22 Mar 2005, Rick Jansen wrote:
Hmm, default configuration is too eager, you index every lexem using simple
dictionary) ! Probably, it's too much. Here is what I have for my russian
configuration in dictionary database:
defaul
On Wed, 23 Mar 2005 12:11:56 +0800, Michael Ryan S. Puncia
<[EMAIL PROTECTED]> wrote:
>
> I have an experience using LIKE in a VARCHAR column and select statement
> suffers a lot so I decided to go back in CHAR
>
> Note: my database has about 50 millions records a b tree index
Strange...
Accord
I have an experience using LIKE in a VARCHAR column and select statement
suffers a lot so I decided to go back in CHAR
Note: my database has about 50 millions records a b tree index
> Can I use an index on a varchar column to optimize the SELECT queries
> that
> use " column LIKE 'header%'
Oleg Bartunov wrote:
On Tue, 22 Mar 2005, Rick Jansen wrote:
Hmm, default configuration is too eager, you index every lexem using
simple dictionary) ! Probably, it's too much. Here is what I have for my
russian configuration in dictionary database:
default_russian | lword| {en_ispell,en
13 matches
Mail list logo
