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 dumb. I've found some
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 execute a single
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
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
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 150 MB to
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
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
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, it shaved
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
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 that's used for
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 updates
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 close at least.
David Griffiths wrote:
Yes, the query operates only on indexed columns (all numeric(10)'s).
Column |Type |
Modifiers
---+-+--
---
user_account_id |
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 than in the
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
I'm just
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 we wouldn't be
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 FreeBSD :(
JB Not our
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 requires a kernel
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 it? That's
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
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
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
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 how
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?
Tweak shmmax and
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 got
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
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#
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
+ if
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 template
29 matches
Mail list logo
