Yes, indeed, sysctl can tweak these values fairly adequately.
Now, numbers of semaphors are not as readily tweaked; I wound up
limited, the other day, when I tried setting values for...
kern.ipc.semmns
kern.ipc.semmni
Same. Maybe that was the option I was thinking was read-only:
houston# sy
If shmmax and shmmall are too small, then:
PostgreSQL requires some more shared memory to cache some tables, x
Mb, do you want to increase your OS kernel parameters?
Tweak shmmax and shmmall
CK> Note that this still requires a kernel recompile on FreeBSD :(
According to whom? sysctl is your fri
Done as you suggested.
---
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > OK, patch attached and applied. It centralizes the optimization
> > defaults into configure.in, rather than having CFLAGS= in the te
Centuries ago, Nostradamus foresaw when [EMAIL PROTECTED] (Vivek Khera) would write:
>> "JB" == Josh Berkus <[EMAIL PROTECTED]> writes:
>
> JB> Chris,
>>> > PostgreSQL requires some more shared memory to cache some tables, x Mb,
>>> > do you want to increase your OS kernel parameters?
>>> >
>>>
Sean Chittenden <[EMAIL PROTECTED]> writes:
> Every few months one of the uber core BSD hackers threatens to rewrite
> that part of PG because high up in the BSD camp, it's common belief
> that shm* is a source of performance loss for PostgreSQL.
They're full of it. RAM is RAM, no? Once you've
Seth Ladd <[EMAIL PROTECTED]> writes:
> My Table Columns (all bigints): start, stop, step1, step2, step3
^^^
> The Query: explain analyze select * from path where start = 653873 or
> start = 649967 or stop = 653873 or stop = 649967
> Does anyone have a suggestion on
Seth,
> The Query: explain analyze select * from path where start = 653873 or
> start = 649967 or stop = 653873 or stop = 649967
you need to cast all those numbers to BIGINT:
select * from path where start = 653873::BIGINT or
start = 649967::BIGINT or stop = 653873::BIGINT or stop = 649967::
Hello,
Thanks to all the previous suggestions for my previous question. I've
done a lot more research and playing around since then, and luckily I
think I have a better understanding of postgresql.
I still have some queries that don't use an index, and I was wondering
if there were some ot
Bruce Momjian <[EMAIL PROTECTED]> writes:
> OK, patch attached and applied. It centralizes the optimization
> defaults into configure.in, rather than having CFLAGS= in the template
> files.
I think there's a problem here:
> + # configure sets CFLAGS to -O2 for gcc, so this is only for non-gcc
>
David,
> shared_buffers = 96000 # min max_connections*2 or 16, 8KB each
This seems a little high to me, even for 2gb RAM. What % of your available
RAM does it work out to?
> effective_cache_size = 6000 # typically 8KB each
This is very, very low. Given your hardware, I'd set it
On Sat, Oct 11, 2003 at 10:43:04AM +0100, Chris Faulkner wrote:
> I have two very similar queries which I need to execute. They both
> have exactly the same from / where conditions. When I execute the
> first, it takes about 16 seconds. The second is executed almost
> immediately after, it takes 13
On Mon, 2003-10-13 at 14:43, David Griffiths wrote:
> I've been having performance issues with Postgres (sequential scans vs
> index scans in an update statement). I've read that optimizer will
> change it's plan based on the resources it thinks are available. In
> addition, I've read alot of confl
> "SD" == Shridhar Daithankar <[EMAIL PROTECTED]> writes:
SD> If you have 150MB type of data as you said last time, you could
SD> take a pg_dump of database, drop the database and recreate it. By
SD> all chances it will take less time than compacting a database from
SD> 2GB to 150MB.
That's i
> "CK" == Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> If shmmax and shmmall are too small, then:
>> PostgreSQL requires some more shared memory to cache some tables, x
>> Mb, do you want to increase your OS kernel parameters?
>> Tweak shmmax and shmmall
CK> Note that this still req
I've been having performance issues with Postgres
(sequential scans vs index scans in an update statement). I've read that
optimizer will change it's plan based on the resources it thinks are available.
In addition, I've read alot of conflicting info on various parameters, so I'd
like to sor
> "JB" == Josh Berkus <[EMAIL PROTECTED]> writes:
JB> Chris,
>> > PostgreSQL requires some more shared memory to cache some tables, x Mb,
>> > do you want to increase your OS kernel parameters?
>> >
>> >Tweak shmmax and shmmall
>>
>> Note that this still requires a kernel recompile on Fre
> > > PostgreSQL requires some more shared memory to cache some
> > > tables, x Mb, do you want to increase your OS kernel parameters?
> > >
> > >Tweak shmmax and shmmall
> >
> > Note that this still requires a kernel recompile on FreeBSD :(
>
> Not our fault, now is it? This would mean that
> >> echo "effective_cache_size = $((`sysctl -n vfs.hibufspace` / 8192))"
> >>
> >> I've used it for my dedicated servers. Is this calculation correct?
>
> SC> Yes, or it's real close at least. vfs.hibufspace is the amount
> of SC> kernel space that's used for caching IO operations (minus the
>
> And what about commercial_entity.user_account_id. Is it indexed and what
> is its data type (i.e. does it match numeric(10,0))?
Yup - all columns in the statement are indexed, and they are all
numeric(10,0).
> Also, have you run VACUUM ANALYZE lately?
Yup - just before the last run.
Will get
On Mon, 2003-10-13 at 01:53, Andriy Tkachuk wrote:
> > >>Do you know of any RDBMS that actually will execute a single query
> > >>on multiple processors?
> > >
> Oracle, i think, on partitioned tables.
This makes a certain amount of sense. It be much easier to allow this
on partitioned tables t
David Griffiths wrote:
Yes, the query operates only on indexed columns (all numeric(10)'s).
Column |Type |
Modifiers
---+-+--
---
user_account_id | numeric
On Monday 13 October 2003 19:34, Vivek Khera wrote:
> > "SC" == Sean Chittenden <[EMAIL PROTECTED]> writes:
> >>
> >> echo "effective_cache_size = $((`sysctl -n vfs.hibufspace` / 8192))"
> >>
> >> I've used it for my dedicated servers. Is this calculation correct?
>
> SC> Yes, or it's real clo
On Monday 13 October 2003 19:22, Seum-Lim Gan wrote:
> I am not sure I can do the full vacuum.
> If my system is doing updates in realtime and needs to be
> ok 24 hours and 7 days a week non-stop, once I do
> vacuum full, even on that table, that table will
> get locked out and any quiery or update
> "SC" == Sean Chittenden <[EMAIL PROTECTED]> writes:
>> echo "effective_cache_size = $((`sysctl -n vfs.hibufspace` / 8192))"
>>
>> I've used it for my dedicated servers. Is this calculation correct?
SC> Yes, or it's real close at least. vfs.hibufspace is the amount of
SC> kernel space tha
I am not sure I can do the full vacuum.
If my system is doing updates in realtime and needs to be
ok 24 hours and 7 days a week non-stop, once I do
vacuum full, even on that table, that table will
get locked out and any quiery or updates that come in
will timeout.
Any suggestion on what to do besid
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Vivek Khera
Sent: Viernes, 10 de Octubre de 2003 03:14 p.m.
To: Josh Berkus
Cc: [EMAIL PROTECTED]
Subject: Re: [PERFORM] go for a script! / ex: PostgreSQL vs. MySQL
> "JB" == Josh Berkus <[EMAIL PROTECT
> "BM" == Bruce Momjian <[EMAIL PROTECTED]> writes:
BM> COPY only does fsync on COPY completion, so I am not sure there are
BM> enough fsync's there to make a difference.
Perhaps then it is part of the indexing that takes so much time with
the WAL. When I applied Marc's WAL disabling patch,
David Griffiths wrote:
It's a slight improvement, but that could be other things as well.
I'd read that how you tune Postgres will determine how the optimizer works
on a query (sequential scan vs index scan). I am going to post all I've done
with tuning tommorow, and see if I've done anything dum
Seum-Lim Gan wrote:
I have a table that keeps being updated and noticed
that after a few days, the disk usage has growned to
from just over 150 MB to like 2 GB !
Hmm... You have quite a lot of wasted space there..
I followed the recommendations from the various search
of the archives, changed the m
On Mon, 13 Oct 2003, Seum-Lim Gan wrote:
> Hi,
>
> I did a search in the discussion lists and found several
> pointers about setting the max_fsm_relations and pages.
>
> I have a table that keeps being updated and noticed
> that after a few days, the disk usage has growned to
> from just over 15
Hi,
I did a search in the discussion lists and found several
pointers about setting the max_fsm_relations and pages.
I have a table that keeps being updated and noticed
that after a few days, the disk usage has growned to
from just over 150 MB to like 2 GB !
I followed the recommendations from the
Actually, even Microsoft SQL Server will do this for you (you can even
chose if it shoudl split it up on all processors or a maximum number).
Will do it on any types of queries, as long as they're big enough (you
can tweak the cost limit, but the general idea is only process
CPU-expensive queries t
On Fri, 10 Oct 2003, Bill Moran wrote:
> johnn wrote:
> > On Fri, Oct 10, 2003 at 12:42:04PM -0400, Bill Moran wrote:
> >
> >>4) It simply isn't practical to expect a single query to
> >> execute on multiple processors simultaneously.
> >>
> >>Do you know of any RDBMS that actually will exec
Oh, Gaetano, didn't you see in my first letter of this topic
that args are the same in session (they are constant)?
The first paragraf of my first letter of this topic was:
< Hi folks. I notice that immutable flag does nothing when i invoke
< my plpgsql function within one session with same args.
34 matches
Mail list logo
