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
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%'
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
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
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
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
"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?
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
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 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
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 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
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
13 matches
Mail list logo
