end
up with this problem.
1G is probably too much memory to allocate for work_mem.
--
Bill Moran
Collaborative Fusion Inc.
http://people.collaborativefusion.com/~wmoran/
[EMAIL PROTECTED]
Phone: 412-422-3463x4023
IMPORTANT: Th
RAID-10 or similar, or somehow get a faster disk.
You always have the option to turn off fsync, but be sure you understand
the consequences of doing that and have an appropriate failure plan
before doing so.
--
Bill Moran
Collaborative Fusion Inc.
http://people.collaborativefusion.com/~wmoran/
[EM
In response to Greg Smith <[EMAIL PROTECTED]>:
> On Thu, 28 Aug 2008, Bill Moran wrote:
>
> > In linux, it's possible to tell the OOM killer never to consider
> > certain processes for the axe, using /proc magic. See this page:
> > http://linux-mm.org/OOM_Ki
ertain processes for the axe, using /proc magic. See this page:
http://linux-mm.org/OOM_Killer
Perhaps this should be in the PostgreSQL docs somewhere?
--
Bill Moran
Collaborative Fusion Inc.
http://people.collaborativefusion.com/~wmoran/
[EMAIL PROTECTED]
Phone: 412-422-3463x4023
--
Sent v
the solution to problems like these. Not to mention the historical
data generally tells you months ahead of time when you're going to
need to scale up to bigger hardware.
On a side note, what version of PG are you using? If it was in a
previous email, I missed it.
Hope this helps.
--
Bill
ou remove smaller groups of rows more frequently, you'll
probably be able to maintain performance and table bloat at a reasonable
level with normal vacuum.
--
Bill Moran
Collaborative Fusion Inc.
[EMAIL PROTECTED]
Phone: 412-422-3463x4023
--
Sent via pgsql-performance mailing list (pgsq
In response to Steve Atkins <[EMAIL PROTECTED]>:
>
> On Aug 12, 2008, at 8:21 AM, Bill Moran wrote:
>
> > In response to Moritz Onken <[EMAIL PROTECTED]>:
> >
> >>
> >> Am 12.08.2008 um 17:04 schrieb Bill Moran:
> >>
> >>>
In response to Moritz Onken <[EMAIL PROTECTED]>:
>
> Am 12.08.2008 um 17:04 schrieb Bill Moran:
>
> > In response to Moritz Onken <[EMAIL PROTECTED]>:
> >
> >> We chose UUID as PK because there is still some information in an
> >> integer ke
in a specific period of
> time
> (compare the id of the newest user to the id a week ago). This is
> information
> which is in some cases critical.
So you're accidentally storing critical information in magic values
instead of storing it explicitly?
Good luck with that.
--
with a system ID (i.e. make the high 8 bits the
system ID and the remaining bits come from a sequence) This allows
you to still use int4 or int8.
UUID is designed to be a universal solution. But universal solutions
are frequently less efficient than custom-tailored solutions.
--
Bill Moran
lus any network
delays and time required to process the query and result on the client
side.
--
Bill Moran
Collaborative Fusion Inc.
[EMAIL PROTECTED]
Phone: 412-422-3463x4023
IMPORTANT: This message contains confidential info
lable RAM" is meant the free RAM after all other applications
are running, which will be 4G if this machine only runs PostgreSQL, but
could be less if it runs other things like a web server.
--
Bill Moran
Collaborative Fusion Inc.
http://people.collaborativefusion.com/~wmoran/
[EMAIL PROTECTED
aise the FSM settings to allow vacuum to work,
then lower them back down when it's under control again. This is one
of the few circumstances where you may want to VACUUM FULL.
If you don't handle this, that table will continue to grow in size on
the disk, taking up space unnecessarily an
d to look at limiting it based on
> how much memory your server has.
I do have one thing to add: if you're using 8.3, there's a log_temp_files
config variable that you can use to monitor when your sorts spill over
onto disk. It doesn't change anything that Scott said, it simply give
, and
> if you have good ideas about relevant topics, please let me know.
>
> Please let me know, I'd be very happy if you could contribute...
> (Don't worry about language!)
> :-)
Can you provide detailed information on submission guidelin
G btree
> ("IDLocker");
>
> CREATE INDEX
> idx_fk_lockerevents_idmoneysymbol_moneysymbols_id
> ON "LockerEvents"
> USING btree
> ("IDMoneySymbol");
>
> CREATE INDEX idx_fk_lockerevents_iduser_users_id
> ON "LockerEvents"
> USING btre
In response to Greg Smith <[EMAIL PROTECTED]>:
> On Wed, 16 Apr 2008, Bill Moran wrote:
>
> >> bgwriter_delay = 1ms # 10-1ms between rounds
> >> bgwriter_lru_maxpages = 1000 # 0-1000 max buffers written/round
> > Have you watched closely
pot
at the values you mention. However, if that really is the demonstrable
sweet spot, there may be something we all can learn.
--
Bill Moran
Collaborative Fusion Inc.
http://people.collaborativefusion.com/~wmoran/
[EMAIL PROTECTED]
Phone: 412-422-3463x4023
--
Sent via pgsql-performance mailing lis
anybody give me some advice on the above? I'm not sure where to
> start looking or how to start looking
Running VACUUM VERBOSE will give you a detailed view of space usage of
each individual table.
--
Bill Moran
Collaborative Fusion Inc.
[EMAIL PROTECTED]
Phone: 412-422-3463x4023
--
Sent
expect that the pg_dump format is able to do more aggressive
compression than the running database.
--
Bill Moran
Collaborative Fusion Inc.
http://people.collaborativefusion.com/~wmoran/
[EMAIL PROTECTED]
Phone: 412-422-3463x4023
--
Sent via pgsql-performance mailing list (pgsql-performance@postgres
ostgreSQL's internals and see what tables are in the buffer in real
time. If you're having trouble, it can (potentially) be a helpful
tool.
--
Bill Moran
Collaborative Fusion Inc.
http://people.collaborativefusion.com/~wmoran/
[EMAIL PROTECTED]
Phone: 412-422-3463x4023
--
Se
s (term) MATCH SIMPLE
> > ON UPDATE NO ACTION ON DELETE NO ACTION,
> > CONSTRAINT gene_prediction_view_gene_ref_key UNIQUE (gene_ref, go_id)
> > )
> > WITH (OIDS=FALSE);
> > ALTER TABLE gene_pre
In response to Greg Smith <[EMAIL PROTECTED]>:
> On Mon, 7 Apr 2008, Bill Moran wrote:
>
> > You know, with all the performance problems people have been bringing up
> > with regard to SANs, I'm putting SAN in the same category as RAID-5 ...
>
> Not really
mailpref/pgsql-performance
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
--
Bill Moran
Collaborative Fusion Inc.
http://people.collaborativefusion.co
838,1377100,969316,1796618,1121046,4662009,963535,5302610,1121105,688700,688743,688836,688763,688788,1056859,2386006,2386015,2386023,4265832,4231262,4265743,5302612,1121056,11
21
> 090,1121074,688659,688650}'::integer[]))
> -> Inde
ems with
the results you're getting, they're about what I would expect. Are you
trying to compare PostgreSQL to MySQL/MyISAM? More directly, what is
your purpose in starting this email conversation? What are you hoping
to accomplish?
--
Bill Moran
Collaborative Fusion Inc.
http://p
; Total runtime: 6259.543 ms
6 seconds doesn't sound like an unreasonable amount of time to count 3
million rows. I don't see any performance issue here.
What were your expectations?
--
Bill Moran
Collaborative Fusion Inc.
http://people.collaborativefusion.com/~wmoran/
[EMAIL PROTECT
s and blocks, etc) so
you have all that processing overhead as well. What filesystem did you
format the RAM disk with?
Why are you doing this? If you have enough RAM to store the table, why
not just allocate it to shared buffers?
--
Bill Moran
Collaborative Fusion Inc.
http://people.collabo
UNT.
The real question (to verify Tom's point) is does a _second_ SELECT count()
modify the table again? If so, then something else is going on than
what Tom suggested.
--
Bill Moran
Collaborative Fusion Inc.
http://people.collaborativefusion.com/~wmoran/
[EMAIL PROTECTED]
Phone: 412-422-34
magine of a select that modifies database
data, but it's hardly the only one. I suspect that the OP has procedures
in his SELECTs that are modifying table data, or triggers that do it ON
SELECT or something similar.
Of course, without any details, this is purely speculation.
--
Bill Moran
ether a
simple, reproducible case that others can use to reproduce the behaviour
on systems where they can investigate it. Once you have that, use the
bug reporting form on the web site to report it as a bug.
--
Bill Moran
Collaborative Fusion Inc.
http://people.collaborativefusion.com/~wmoran
of RAM, you might want to try bumping this and
see if it helps without pushing the system into swap. If the problem
is sort file usage, this is the option to tune it.
> maintenance_work_mem = 4GB
I doubt it's hurting anything, but I don't think a value this high will
actually be used
action updating or inserting to Table A via the after
> trigger (insert, update)
>
> - Function D (insert, update, delete)
>
> Table C is processed ONLY by function D (insert, update, delete). Nothing
> else touches it;
>
> PG_LOCKS table verifies that that this table is t
)).
>
> Sorry, if I am missing something here, but shouldn't something like this
> allow us to get a (fast) accurate count ?
>
> SELECT COUNT(*) from table WHERE indexed_field IS NULL
> +
> SELECT COUNT(*) from table WHERE indexed_field IS NOT NULL
For certain, qualified d
uickly available.
Another is to use EXPLAIN to get an estimate of the # of rows from
the planner. This works well if an estimate is acceptable, but can't
be trusted for precise counts.
Some searches through the archives should turn up details on these
methods.
--
Bill Moran
Collaborative Fus
autovacuum running,
reduce those values.
Personally, I'd recommend running a MRTG graph that graphs the size
of this table so you can easily watch to see if your config tweaks
are getting the job done or not. And remember that _some_ bloat is
expected and normal for operation.
--
Bill Mor
s table - just inserts, lots of updates?
> >
> > 2. What does SELECT sum(length(log)) FROM dataaction; show?
> >
> >
> > > Vacuum on the table doesn't finish.
> >
> >
> > A plain vacuum doesn't finish, or vacuum full doesn't finis
nd I don't hear anyone
denying that. As I said, google around a bit WRT to PG storing
visibility information in indexes, as I think that's the way this will
be improved.
> My rant for today...
Feel better now?
--
Bill Moran
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.org&extra=pgsql-performance
a count column, or using explain to get a quick estimate of
the number of rows (if that's acceptable).
--
Bill Moran
Collaborative Fusion Inc.
http://people.collaborativefusion.com/~wmoran/
[EMAIL PROTECTED]
Phone: 412-422-3463x4023
*
; Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
> > To make changes to your subscription:
> >
> > http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.org&extra=pgsql-performance
> >
>
> --
> Sent via pgsql-performance mailing li
u need to be running the 7.X branch.
Based on your pgbench results, I'm guessing you didn't get battery-backed
cache on your systems? That makes a big difference no matter what OS
you're using.
Besides that, I can't think of any FreeBSD-specific things to do. Basically,
genera
kes enough of a difference to be doing all of this work.
> again, tia. i feel like such a noob around here :)
Bah ... we all start out as noobs. Just don't go googling for my posts
from years back, it's embarrassing ...
--
Bill Moran
Collaborative Fusion Inc.
http://people.collabor
)
> or
> on the underlying index (index on lastname)?
If cluster helps you at all, it's going to help if you have an index that's
frequently used to fetch ranges of data. Whether that index is compound or
not isn't likely to factor in.
--
Bill Moran
Collaborative Fusion
me a link where I can find a WAR file.
I think you're going to have to be more specific. I don't know what
technology uses WAR files, and based on the tepid response, it doesn't
seem like anyone else on the list does either.
What program are you using that uses the WAR file
ke it's worth the
effort, but if it's run 1x10^25 times a day it is. If the IO load of
logging all queries presents too much of a slowdown, I recommend selecting
data collection periods and do it for perhaps an hour, then turn it
back off. Maybe once a week or so.
Hope th
In response to Mark Mielke <[EMAIL PROTECTED]>:
> Bill Moran wrote:
> > In response to Mark Mielke <[EMAIL PROTECTED]>:
> >
> >
> >> Bill Moran wrote:
> >>
> >>> I'm fairly sure that FreeBSD's GEOM does.
In response to Mark Mielke <[EMAIL PROTECTED]>:
> Bill Moran wrote:
> >
> >> What do you mean "heard of"? Which raid system do you know of that reads
> >> all drives for RAID 1?
> >>
> >
> > I'm fairly sure that FreeBSD&#
In response to Mark Mielke <[EMAIL PROTECTED]>:
> Bill Moran wrote:
> > In order to recalculate the parity, it has to have data from all disks.
> > Thus,
> > if you have 4 disks, it has to read 2 (the unknown data blocks included in
> > the parity calculation)
said, I have heard of raid1 setups where it only reads off of one
> > of the drives, but I have not heard of higher raid levels doing so.
> What do you mean "heard of"? Which raid system do you know of that reads
> all drives for RAID 1?
I'm fairly sure that FreeBSD&#x
es which don't have noticable seek
> > times, things are completely different ;-)
>
> Ha, sadly budget is very tight. :)
Budget is always tight. That's why you don't want a RAID 5. Do a RAID 5
now thinking you'll save a few bucks, and you'll be spending twice tha
RAID 10.
I snipped the rest of your message because none of it matters. Never use
RAID 5 on a database system. Ever. There is absolutely NO reason to
every put yourself through that much suffering. If you hate yourself
that much just commit suicide, it's less drastic.
--
Bill
In response to "Joshua D. Drake" <[EMAIL PROTECTED]>:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Fri, 14 Dec 2007 11:18:49 -0500
> Bill Moran <[EMAIL PROTECTED]> wrote:
>
> > > That is like saying anyone that has rights to call a w
t have rights to execute the functions
> but they can see the source code for them. Shouldn't I be able to revoke
> both the ability to execute and the ability to see functions?
Um ... why did you snip my second paragraph where I said exactly this?
--
Bill Moran
Collaborative F
oach. As a result, what _really_ needs to
be done is an extra permission bit added to functions so administrators
can control who can view the function body.
--
Bill Moran
Collaborative Fusion Inc.
http://people.collaborativefusion.com/~wmoran/
[EMAIL PROTECTED]
Phone: 412-422-3463x4023
tten (or appropriate indexes added, or whatever) EXPLAIN can
be your friend once you've found problematic queries.
Another piece of broadly useful advice is to install the pgbuffercache
addon and monitor shared_buffer usage to see if you've got enough. Also
useful is monitoring the
YSE" recently?
I don't know about the "FULL" part ... but certainly an ANALYZE.
Please post EXPLAIN ANALYZE output for the two queries.
--
Bill Moran
Collaborative Fusion Inc.
http://people.collaborativefusion.com/~wmoran/
[EMAIL PROTECTED]
Phone: 412-422-3463x4023
**
In response to Gregory Stark <[EMAIL PROTECTED]>:
> "Bill Moran" <[EMAIL PROTECTED]> writes:
>
> > In response to Matthew <[EMAIL PROTECTED]>:
> >
> >> On Tue, 27 Nov 2007, Pablo Alcaraz wrote:
> >> > it would be nice to do some
In response to Csaba Nagy <[EMAIL PROTECTED]>:
> On Wed, 2007-11-28 at 08:27 -0500, Bill Moran wrote:
> > Is there something wrong with:
> > set enable_seqscan = off
> > ?
>
> Nothing wrong with enable_seqscan = off except it is all or nothing type
> of thi
; database.
Is there something wrong with:
set enable_seqscan = off
?
--
Bill Moran
Collaborative Fusion Inc.
http://people.collaborativefusion.com/~wmoran/
[EMAIL PROTECTED]
Phone: 412-422-3463x4023
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
r faster disks will
improve this situation are probably 90% or better.
Other things that could cause this problem are poor schema design, and
unreasonable expectations.
--
Bill Moran
Collaborative Fusion Inc.
http://people.collaborativefusion.com/~wmoran/
[EMAIL PROTECTE
g = sql_ascii# actually, defaults to
> database
> # encoding
>
> # These settings are initialized by initdb -- they might be changed
> lc_messages = 'it_IT.UTF-8' # locale for system
> error message
>
it hasn't moved from
8.1 -> 8.2. The comment is that it's bad because it hasn't updated a
major branch with the latest bug fixes. i.e. it hasn't moved from 8.1.4
to 8.1.5.
If this is indeed the case, I agree that such a distro isn't worth using.
--
Bill Moran
Collab
ates materialized_topics
any time the first table is altered. Thus you always have fast lookups.
Of course, this may be non-optimal if that table sees a lot of updates.
--
Bill Moran
Collaborative Fusion Inc.
http://people.collaborativefusion.com/~wmoran/
[EMAIL PROTECTED]
Phone: 412-422-3463x4023
---(end of broadcast)---
TIP 6: explain analyze is your friend
ram the
process holding the transaction open to do a vacuum full of that table
when it's done with it's work.
--
Bill Moran
Collaborative Fusion Inc.
http://people.collaborativefusion.com/~wmoran/
[EMAIL PROTECTED]
Phone: 412-422-3463x4023
*
re to track when sorts don't fit in
work_mem.
--
Bill Moran
Potential Technologies
http://www.potentialtech.com
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
> involved and there are no joins. It's testing very low-level aspects of
> performance.
Actually, what it's really showing is parallelism, and I've always
expected PostgreSQL to come out on top in that arena.
--
Bill Moran
Potential Technologies
http://www.potentialtech
aybe a cron
that vacuums that table every 5 minutes.
You could also do a combination, i.e. enable autovacuum with conservative
settings and set a cron to vacuum the table every 10 minutes.
Vacuuming once a day is usually only enough if you have very minimal
updates.
--
Bill Moran
Collabora
In response to Ron St-Pierre <[EMAIL PROTECTED]>:
> Bill Moran wrote:
> > In response to Ron St-Pierre <[EMAIL PROTECTED]>:
> >
> >
> >> We vacuum only a few of our tables nightly, this one is the last one
> >> because it takes longer to run
2000
> deadlock_timeout = 1
> max_locks_per_transaction = 640
> add_missing_from = on
>
> As I mentioned, any insights into changing the configuration to optimize
> performance are most welcome.
>
> Thanks
>
> Ron
>
> ---(end of broadc
78 kB shared
> memory.
> VACUUM
This doesn't look problematic, so I doubt your vacuum policy is to blame.
--
Bill Moran
Collaborative Fusion Inc.
http://people.collaborativefusion.com/~wmoran/
[EMAIL PROTECTED]
Phone: 412-422-3463x4023
---(end of broadcast)---
us the explain.
However, 2 guesses:
1) You never analyzed the table, thus PG has awful statistics and
doesn't know how to pick a good plan.
2) You have so few rows in the table that a seq scan is actually
faster than an index scan, which is why PG uses it
ep up the vacuum schedule you've already
established. You may want to (as has already been suggested) explicitly
vacuum this table after large delete operations as well.
--
Bill Moran
Collaborative Fusion Inc.
http://people.collaborativefusion.com/~wmoran/
[EMAIL PROTECTED]
Phone: 412-422-3463x4023
in the same server there
> aren't networks delays!
Not network, no. But the results of your explains seem to show that the
query is executing much faster on the new system than the old, so the
problem still becomes, "what is happening after the query completes that
is so slow?"
ery, in the old one, in the new one), without difference and I only
> retrieve the first 100 records (I didn't count the network time in any case).
> But the weird thing is running the query in the new server the are many disk
> access and cpu usage. And wi
>
> Index Cond: (qa.answer_id = "outer".id)
>
>
> -> BitmapOr (cost=55.08..55.08 rows=6596 width=0) (never e
anner faster.
>
> Do you think it could be reasonable?
Based on the information you've given and the responses you've made,
I think you're as likely to roll a 1d6 and get the right solution as
anything else.
Good luck.
> -Messaggio originale-
> Da: Bil
gt; Generally it's faster to run more commands in a single transaction but what
> I'm worried about is that you may have a transaction open which you aren't
> committing for a long time. This can stop vacuum from being able to clean up
> dead space and if it's in t
x27;ll see detailed log
messages about its activities.
There were discussions on other lists about improving autovacuum's log
messages, I'm pretty sure it will log more helpful information in 8.3.
--
Bill Moran
Collaborative Fusion Inc.
http://people.collaborativefusion.com/~wmoran/
[EMAIL PR
mance related stuff.
>
> Thank you all in advance
To add to Mikko's comments:
Periodic vacuuming and analyzing is a mandatory part of running a
PostgreSQL database server. You'll probably be best served to configure
the autovacuum daemon to handle this for you. See the postgre
ay with a lot less
space than many other usages, so they might be very practical.
--
Bill Moran
Collaborative Fusion Inc.
http://people.collaborativefusion.com/~wmoran/
[EMAIL PROTECTED]
Phone: 412-422-3463x4023
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
re not obvious to me. The explain analyze output is
going to be key to working this out -- unless it's something like
your postgresql.conf isn't properly tuned.
> I vacuum and
> reindex the database daily.
>
> I'd prefer not to have to rewrite th
ou autovacuum or vacuum manually?
> Tell us more...
>
>
> Bye,
> Chris.
>
>
>
> ---(end of broadcast)---
> TIP 3: Have you checked our extensive FAQ?
>
>http://www.postgresql
> You can't use these techniques for a major version upgrade.
> Use pg_dump piped to psql. That will also eliminate all bloat.
If you can't afford any downtime, you may be able to use Slony to
do your upgrade. However, slony adds overhead, and if this system
is tapped out already, i
ons on a server if needed, the
> ability to quickly revert to a previous version, etc however this is a
> discussion for another day - I only mention it in case the question "why not
> just use RPM's?" arises...
>
>
> So here's my questions:
>
> 1
e any difference ?
Does the documentation leave anything unanswered?
http://www.postgresql.org/docs/8.2/static/runtime-config-locks.html
--
Bill Moran
Collaborative Fusion Inc.
http://people.collaborativefusion.com/~wmoran/
[EMAIL PROTECTED]
Phone: 412-422-3463x4023
---(end o
In response to "Decibel!" <[EMAIL PROTECTED]>:
> On Wed, Aug 08, 2007 at 03:27:57PM -0400, Bill Moran wrote:
> > I've had similar experience. One thing you didn't mention that I've noticed
> > is that VACUUM FULL often bloats indexes. I've mad
UM seems to fix. A FULL seems to fix that, but it appears
to bloat the indexes, thus a REINDEX helps.
I would expect that setting fillfactor to 100 will encourage indexs to bloat
faster, and would only be recommended if you didn't expect the index contents
to change?
--
Bill
r problem, then
you either need to implement a data expiration policy to get rid of
old data, or increase the amount of storage to accommodate the data
you want to keep.
--
Bill Moran
Collaborative Fusion Inc.
http://people.collaborativefusion.com/~wmoran/
[EMAIL PROTECTED]
Phone: 412-422-3463x4023
that process, unless you're running
a 486dx2. You didn't mention your hardware or your postgresql.conf
settings. What other activity is occurring during this long count()?
Can you give us a shot of the iostat output and/or top during this
phenomenon?
>
> Jozsef
>
>
>
t;
> > checkpoint_segments = 16
> >
> >
> >
> >
> >
> > top reports
> >
> >
> >
> > PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
> >
> > 19478 postgres 25 0 740m 721m 536m R 99.7 4.4 609:41.16
>
fers = 16
> >
> > checkpoint_segments = 16
> >
> >
> >
> >
> >
> > top reports
> >
> >
> >
> > PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
> >
> > 19478 postgres 25 0 740m 721m 536m R 99.7 4
prove/disprove that theory:
http://www.postgresql.org/docs/8.2/interactive/view-pg-locks.html
If none of those are the case, then please describe the actual problem
you are having.
HTH.
--
Bill Moran
Collaborative Fusion Inc.
http://people.collaborativefusion.com/~wmoran/
[EMAIL PROTEC
> #cpu_operator_cost = 0.0025 # (same)
> #---
> # LOCK MANAGEMENT
> #---
>
> #deadlock_timeout = 1000
iodic.conf (just like other
periodic job):
daily_pgsql_vacuum_enable="YES"
daily_pgsql_backup_enable="NO"
are the defaults.
> Hmmm... I wonder why this would just start now, three days ago. Everything
> seemed to be normal for the last two weeks.
Someone alter /etc/periodic.conf? Perhaps it
(for me anyway) on a system I don't know so
> much about.
:D Isn't Open Source great!
--
Bill Moran
Collaborative Fusion Inc.
http://people.collaborativefusion.com/~wmoran/
[EMAIL PROTECTED]
Phone: 412-422-3463x4023
G's shared_buffers -- if that's the case, have
a look at the pg_buffercache contrib module.
--
Bill Moran
Collaborative Fusion Inc.
http://people.collaborativefusion.com/~wmoran/
[EMAIL PROTECTED]
Phone: 412-422-3463x4023
---(end of broadcast)---
TIP 6: explain analyze is your friend
exes --- VACUUM FULL isn't good at that.
> >
> > regards, tom lane
> >
> > ---(end of
> > broadcast)---
> > TIP 4: Have you searched our list archives?
> >
> >
that doesn't apply here.
Why not? I see no reason why an appropriate autovaccum schedule would not
apply to your scenario. I'm not saying it does, only that your response
does not indicate that it doesn't, and thus I'm concerned that you're
writing auto
uring initial testing of
our DB) I would run vacuum verbose once a day to watch sizes and what
not. After a while, I'd switch to once a week, then probably settle on
once a month to ensure nothing ever gets out of hand. Put it in a cron
job and have the output mailed.
--
Bill Moran
Col
o see how well autovacuum is keeping up. There's
no problem with running manual vacuum and autovacuum together, and you'll
be able to gather _some_ information about how well autovacuum is
keeping up.
--
Bill Moran
Collaborative Fusion Inc.
http://people.collab
1 - 100 of 200 matches
Mail list logo
