Joshua D. Drake wrote:
The big thing for me, is a single document, zero clicks, that is
searchable. PDF and plain text are the only thing that give me that. If
you are really zealous you can even use Beagle (which I don't) to
preindex the PDF for you for easy searching.
Lots of projects publish
Bruce Momjian wrote:
Tom Lane wrote:
"Matthew T. O'Connor" writes:
Lots of projects publish their HTML docs in two formats: One Big HTML
file with everything; Broken up into many HTML files that link to each
other. This would allow you you have one big searchable document
Larry Rosenman wrote:
I might use that as the base then, since the hardware finishes getting here
tomorrow.
The other thing to consider is that CentOS 5 has Xen built right in, so
you should be able run VMs without VMWare on it.
---(end of broadcast)--
Tom Lane wrote:
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
Our documentation says
| analyze threshold = analyze base threshold
| + analyze scale factor * number of tuples
| is compared to the total number of tuples inserted, updated, or deleted
| since the last ANALYZE.
Florian G. Pflug wrote:
Work done so far:
-
.) Don't start autovacuum and bgwriter.
Do table stats used by the planner get replicated on a PITR slave? I
assume so, but if not, you would need autovac to do analyzes.
---(end of broadcast)-
Alvaro Herrera wrote:
Simon Riggs wrote:
On Wed, 2007-06-06 at 12:17 -0400, Matthew T. O'Connor wrote:
Florian G. Pflug wrote:
Work done so far:
-
.) Don't start autovacuum and bgwriter.
Do table stats used by the planner get replicated on a PITR slave? I
assume
Alvaro Herrera wrote:
Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
But this is misleading (started postmaster with good value, then edited
postgresql.conf and entered "-2"):
17903 LOG: received SIGHUP, reloading configuration files
17903 LOG: -2 is outside the valid range for pa
Tom Lane wrote:
"Andrew Hammond" <[EMAIL PROTECTED]> writes:
Hmmm... it seems to me that points new users towards not using
autovacuum, which doesn't seem like the best idea. I think it'd be
better to say that setting the naptime really high is a Bad Idea.
It seems like we should have an upper
Andrew Dunstan wrote:
The situation with this patch is that I now have it in a state where I
think it could be applied, but there is one blocker, namely that we do
not have a way of preventing the interleaving of log messages from
different backends, which leads to garbled logs. This is an exis
Tom Lane wrote:
"Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
How about creating a log-writing-process? Postmaster could write to the
log files directly until the log-writer is up and running, then all
processes can send their log output through the log-writer.
We
Alvaro Herrera wrote:
Jim C. Nasby escribió:
There *is* reason to allow setting the naptime smaller, though (or at
least there was; perhaps Alvero's recent changes negate this need):
clusters that have a large number of databases. I've worked with folks
who are in a hosted environment and give e
Alvaro Herrera wrote:
Jim C. Nasby wrote:
FWIW, I normally go with the 8.2 defaults, though I could see dropping
vacuum_scale_factor down to 0.1 or 0.15. I also think the thresholds
could be decreased further, maybe divide by 10.
How about pushing thresholds all the way down to 0?
As long a
Alvaro Herrera wrote:
Matthew T. O'Connor wrote:
Well, if a table has 10 rows, and we keep the current threshold of 1000
rows, then this table must have 1002 dead tuples (99% dead tuples, 1002
dead + 10 live) before being vacuumed. This seems wasteful because
there are 500 dead tuples on i
Gregory Stark wrote:
I'm having trouble following what's going on with autovacuum and I'm finding
the existing logging insufficient. In particular that it's only logging vacuum
runs *after* the vacuum finishes makes it hard to see what vacuums are running
at any given time. Also, I want to see wh
Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
This is an interesting idea, but I think it's attacking the wrong
problem. To me, the problem here is that an ANALYZE should not block
CREATE INDEX or certain forms of ALTER TABLE.
I doubt that that will work; in particular I'
Tom Lane wrote:
If you insist on crafting a solution that only fixes this problem for
pg_restore's narrow usage, you'll be back revisiting it before beta1
has been out a month.
I don't know much about what is involved in crafting these solutions,
but it seems we're close to beta and probably
Jonah H. Harris wrote:
On Mon, Jul 21, 2008 at 10:19 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
I don't find this a compelling argument, at least not without proof that
the various vacuum-improvement projects already on the radar screen
(DSM-driven vacuum, etc) aren't going to fix your problem.
Tom Lane wrote:
"Greg Sabino Mullane" <[EMAIL PROTECTED]> writes:
Code outside of core, is, in reality, less reviewed, less likely to work
well with recent PG versions, and more likely to cause problems. It's also
less likely to be found by people, less likely to be used by people, and
less like
Joshua D. Drake wrote:
Merlin Moncure wrote:
Well, there doesn't seem to be a TODO for partial/restartable vacuums,
which were mentioned upthread. This is a really desirable feature for
big databases and removes one of the reasons to partition large
tables.
I would agree that partial vacuums wo
Tom Lane wrote:
"Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
I think everyone agrees that partial vacuums would be useful / *A Good
Thing* but it's the implementation that is the issue.
I'm not sure how important it will really be once we have su
Josh Berkus wrote:
For the September commitfest, 29 patches were applied (one to pgFoundry)
and 18 patches were sent back for more work.
More importantly, six *new* reviewers completed reviews of of various
patches: Abbas Butt, Alex Hunsaker, Markus Wanner, Ibrar Ahmed, Ryan
Bradetich and Gi
Tom Lane wrote:
Andrew Chernow <[EMAIL PROTECTED]> writes:
Be careful. From LockFileEx docs:
"However, the time it takes for the operating system to unlock these
locks depends upon available system resources. Therefore, it is
recommended that your process explicitly unlock all files it has
Kevin Grittner wrote:
An idea for a possible enhancement to PostgreSQL: allow creation of a
temporary table without generating any disk I/O. (Creating and
dropping a three-column temporary table within a database transaction
currently generates about 150 disk writes).
If some circumstances don
Tom Lane wrote:
Decibel! <[EMAIL PROTECTED]> writes:
I think that's pretty seriously un-desirable. It's not at all
uncommon for databases to stick around for a very long time and then
jump ahead many versions. I don't think we want to tell people they
can't do that.
Of course they
Aidan Van Dyk wrote:
* Greg Stark <[EMAIL PROTECTED]> [081117 03:54]:
I thought of saying that too but it doesn't really solve the problem.
Think of what happens if someone sets a hint bit on a dirty page.
If the page is dirty from a "real change", then it has a WAL backup block
record alread
Tom Lane wrote:
However, my comment above was too optimistic, because in an insert-only
scenario autovac would in fact not trigger VACUUM at all, only ANALYZE.
So it seems like we do indeed want to rejigger autovac's rules a bit
to account for the possibility of wanting to apply vacuum to get
vi
Alvaro Herrera wrote:
This seems a good idea. Possibly pushing the betas more aggresively to
current users would make them tested not only by PG hackers ...
Isn't this the purpose of the new alpha releases, at lease to some extent.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgr
Alex Hunsaker wrote:
In fact I
would argue -patches should go away so we dont have that split.
+1I think the main argument for the split is to keep the "large"
patch emails off the hackers list, but I don't think that limit is so
high that it's a problem. People have to gzip their patche
Alex Hunsaker wrote:
A big part of my problem with the split is if there is a discussion
taking place on -hackers I want to be able to reply to the discussion
and say "well, here is what I was thinking". Sending it to -patches
first waiting for it to hit the archive so I can link to it in my
rep
Hans-Juergen Schoenig wrote:
i suggest to introduce a --with-long-xids flag which would give me 62 /
64 bit XIDs per vacuum on the entire database.
this should be fairly easy to implement.
i am not too concerned about the size of the tuple header here - if we
waste 500 gb of storage here i am t
Tom Lane wrote:
We might have to rearrange the logic a bit to make that happen (I'm not
sure what order things get tested in), but a log message does seem like
a good idea. I'd go for logging anytime an orphaned table is seen,
and dropping once it's past the anti-wraparound horizon.
Is there a
> However, others don't believe constraints other than foreign keys
> should go unchecked.
>
> That said, is this functionality wanted outside of pg_dump /
> pg_restore?
pg_dump should reload a database as it was stored in the previous database.
If your old data is not clean, pg_dump / restore
>From the ToDo list:
Vacuum: * Provide automatic running of vacuum in the background (Tom)
As of 7.2 we have lazy vacuum. The next logical step is setting up vacuum to
run automatically in the background either as some type of daemon or as
something kicked off by the postmaster.
I am
On Saturday 29 June 2002 08:14 pm, Tom Lane wrote:
> Launching VACUUMs on some automatic schedule, preferably using feedback
> about where space needs to be reclaimed, seems like a pretty
> straightforward small-matter-of-programming. The thing that would
> really be needed to make it unobtrusive
> The question is not how to replace some .EXE and .DLL files or modify
> something in the registry. The question is what to do with the existing
> databases in the case of a catalog version change. You have to dump and
> restore.
pg_upgrade?
Otherwise: no upgrades persay, but you can intall th
> > Keys to this working:
> > 1.) Must not require the old version executable backend. There are a
number
> > of reasons why this might be, but the biggest is due to the way much
> > upgrading works in practice -- the old executables are typically gone by
the
> > time the new package is inst
On Mon, 2002-07-29 at 08:53, [EMAIL PROTECTED] wrote:
> > Just a long standing curiosity?
> e) Inertia. MySQL got more popular way back when; the reasons may no longer
f) Win32 Support. I can download a setup.exe for mysql and have it up
and running quickly on Windows. I think that native Win
I have been getting this for at least two days:
[matthew@zeut src]$ cvs -v
Concurrent Versions System (CVS) 1.11.2 (client/server)
[matthew@zeut src]$ cvs -z3 -d
:pserver:[EMAIL PROTECTED]:/projects/cvsroot co -P pgsql
[...]
cvs server: Updating pgsql/src/backend/utils/mb/conversion_procs/asc
Hello, I'm playing with creating an auto vacuum daemon, but it is my first
time inside the pg source code and I'm a bit lost.
I have gotten as far as having a vacuum daemon created on postmaster startup.
It's just a fork from the postmaster, cribbed mostly from the stat collector
code.
Insi
when I feel more confident as to what I'm
talking about.
On Friday 16 August 2002 10:10 am, Jan Wieck wrote:
> "Matthew T. O'Connor" wrote:
> > Hello, I'm playing with creating an auto vacuum daemon, but it is my
> > first time inside the pg source code and
> > > Anyone want to argue that we should keep the v0 protocol support any
> > > longer?
> >
> > Nope, exactly the same thought crossed my mind while I was reading
> > through the code...
>
> Feel free to rip it out.
Should probably be mentioned in the release notes.
-
On Saturday 07 September 2002 12:52 pm, Bruce Momjian wrote:
> Peter Eisentraut wrote:
> > Didn't we want to remove that option?
>
> I didn't know it was still in there. I see no reason for it.
How about --enable-depend, that's not still needed is it? Or is that
something other than the new de
> It doesn't have to make its way into the postgresql daemon itself -- in
fact since some people like tuning the vacuuming, it makes more sense to
make this a daemon. No, my suggestion is simple that some sort of
auto-vacuumer be compiled as a stand-alone app and included in the standard
postgresq
From: "Tom Lane" <[EMAIL PROTECTED]>
> However, if we are going to put that kind of knowledge into pg_dump,
> it would only be a small further step to have it dump these triggers
> as ALTER TABLE ADD CONSTRAINT commands instead. Which would be a lot
> better for forward compatibility than dumping
Are you compiling from CVS or from a released tarball? The bison
requirement was recently raised to bison 1.5 or above (1.75 was recently
released also.) This is an issue only when compiling from CVS, since
the bison stuff is preprocessed for released tarballs. So you might
want to try the just
On Wed, 2002-11-06 at 01:32, Justin Clift wrote:
> Bruce Momjian wrote:
> >
> > I have copies of Peer Direct's (Jan's company) port of PostgreSQL to
> > Win32, and SRA's port to Win32, and permission to generate a merged
> > patch that can be applied to 7.4.
> >
> > Now that 7.3 is almost complet
> Tom, would you really be able to ask Permaine to retest 7.3? Have a
> feeling we might be able to leverage the PlayStation2 brand name here
> for the Advocacy project.
>
> :-)
>
Anyone try it on an Xbox yet?
---(end of broadcast)---
TIP 6: Have y
Several months ago tried to implement a special postgres backend as an
Auto Vacuum Daemon (AVD), somewhat like the stats collector. I failed
due to my lack of experience with the postgres source.
On Sep 23, Shridhar Daithankar released an AVD written in C++ that acted
as a client program rather
On Thu, 2002-11-28 at 01:58, Shridhar Daithankar wrote:
> There are differences in approach here. The reason I prefer polling rather than
> signalig is IMO vacuum should always be a low priority activity and as such it
> does not deserve a signalling overhead.
>
> A simpler way of integrating wo
On Thursday 28 November 2002 23:26, Shridhar Daithankar wrote:
> On 28 Nov 2002 at 10:45, Tom Lane wrote:
> > "Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> > > interesting thought. I think this boils down to how many knobs do we
> > > need t
On Friday 29 November 2002 00:56, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> But we already have a recycling mechanism for pg_clog. AFAICS,
> >> creating a parallel log file with a separate recycling mechanism is
> >> a study in wasted effort.
> >
> > But
pg_dump, our upgrade process is painful enough having to do a dump, reload.
I think we should be able to guarantee (or at least let much closer to it)
that the process works in all cases.
Personally pg_upgrade would be even nicer.
- Original Message -
From: "Christopher Kings-Lynne" <[EMA
- Original Message -
From: "Shridhar Daithankar" <[EMAIL PROTECTED]>
To: "Matthew T. O'Connor" <[EMAIL PROTECTED]>
Sent: Monday, December 02, 2002 11:12 AM
Subject: Re: [HACKERS] Auto Vacuum Daemon (again...)
> On 28 Nov 2002 at 3:02, Matthew T. O&
> >"\D" works though.)
> >
> >Any objections out there?
>
> My only complaint here is being forced to use the 'shift' key on commands
> that will be common.
\dd perhaps?
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAI
On Tue, 2003-02-11 at 13:01, Tom Lane wrote:
> "Jon Griffin" <[EMAIL PROTECTED]> writes:
> > So it appears that linux at least is way above your 8 meg point, unless I
> > am missing something.
>
> Yeah, AFAIK all recent Linuxen are well above the range of parameters
> that I was suggesting (and ev
> Free space map details
> --
>
> Accesses to the FSM could create contention problems if we're not careful.
Another quick thought for handling FSM contention problems. A backend could
give up waiting for access to the FSM after a short period of time, and just
append it's da
Hello, I'm having a problem vacuum a table and I didn't see an answer using
the fts engine.
I have two questions:
1) Is this a big problem, can it be fixed, do I have to dump / restore this
table?
2) I found this problem from my nightly cron driven vacuum -a -z. When it
hits this error the enti
Yes and no :-). The files were created but all postgres data files are now
idententified by numbers (oids I think), so you will not find a file or
directory anywhere in your filesystem named "mydb", or "mytable".
- Original Message -
From: "Peter Moscatt" <[EMAIL PROTECTED]>
To: <[EMAIL
> > > > > I disagree. Unless you are omniscient, we will only ever have a
partial
> > > > > list.
> > > but there wasn't enough interest for someone to take on
> > > the maintenance.
> >
> > We need someone willing to be a kibo. Or is that too arcane a reference?
>
> Gotta admit, I haven't heard t
> > Actually, the 'multi-day' delay is generally related to posts from ppl
> > that aren't subscribed to the lists that I have to approve manually ...
>
> I have been getting delayed duplicates from people (ie, Tom Lane)
addressed
> to only the hackers list (which I know he's subscribed to). Up t
> A solution, could be to query for the existance of the PK, just before the
> insertion. But there is a little span between the test and the
> insertion, where another insertion from another transaction could void
> the existance test. Any clever ideas on how to solve this? Using
> triggers mayb
> PS: Another idea I'm toying with is to dump out the FSM contents at
> postmaster shutdown and reload them at restart, so that the FSM doesn't
> have to start from ground zero on every restart cycle. But that's
> independent of the management algorithm...
Correct me if I'm wrong, but the FSM is
On Wed, 2003-06-18 at 21:27, Christopher Kings-Lynne wrote:
> Do we have any "killer" features added to 7.4 that we can shout about?
> There's usually been one or two in the past...?
Isn't the index growth problem solved in this release? I think that is
a killer feature that solves a big problem
From: "Tom Lane" <[EMAIL PROTECTED]>
> It would be easy (and essentially free, since libpq already gets the info)
> to add such a notice to psql startup. How do other people feel about
> it? How would you word the notice exactly?
> "psql: server version is FOO, psql version is BAR, some things ma
On Fri, 2003-06-27 at 03:21, James Pye wrote:
> Greets,
>
> Just a thought for a psql enhancement, afiak, it is not easily possible for
> persistent connections to a database in a shell script..
> The ability for psql to remain in the background reading from stdin and
> writing to st
Sorry for the slow response, I was away for the 4th.
On Fri, 2003-07-04 at 14:53, Christopher Browne wrote:
> Vincent Van Leeuwen wrote:
> > 2411 All DBs checked in: -717533400 usec, will sleep for 30 secs.
>
> That sure looks like a 32 bit wraparound bug;
Agreed, please check with pg_autovaccu
for 7.4. Hopefully for 7.5 there will be
something integrated into the backend making this whole issue moot.
Good luck with this, and please email if you have any questions /
problems.
Matthew T. O'Connor
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
I know it's early, but I was just wondering if there would be 7.4 rpms
during beta?
Thanks,
Matthew
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
On Mon, 2003-07-14 at 01:58, Claudio Natoli wrote:
> I'm just (one of the many?) hanging out for this, to justify continued use
> of Postgres to the powers that be. Seems like there has been no word on this
> for a couple weeks, and I'm not even sure whether or not it has made/will
> make it into 7
Hey, I just tried to to a search of the mail archives and got an error.
I was trying to go here:
http://archives.postgresql.org/search.php?q=autovacuum&ps=50&wm=wrd&o=0&ul=http%3A%2F%2Farchives.postgresql.org%2Fpgsql-hackers%2F&m=all&wf=11
and got the following error:
DB err: could not conn
On Wed, 2003-09-03 at 23:50, Tom Lane wrote:
> Does 'ps' show that the stats collector and stats buffer postmaster
> child processes are alive? Are there any suggestive complaints in
> the postmaster's log?
As Adam mentioned, I took a look at his system since the initial report
was about a proble
On Thu, 2003-09-04 at 01:23, Tom Lane wrote:
> Hm. Could it be an IPv6 issue --- that is, the stats collector is alive
> and faithfully listening on some UDP port, but it's not the same port
> the backends try to send to? Given the discussion over the past couple
> of days about bizarre interpret
Ouch... sorry, my fault. I'll fix this tomorrow (Friday) and submit a
patch, or if you want to submit a patch that would be fine. All you
have to do is change the the sql statements to put quotes around the
relation name.
Thanks for catching this.
Matthew T. O'Connor
On Thu, 2003-0
On Thu, 2003-09-04 at 18:39, Adam Kavan wrote:
> Now that I have pg_autovacuum working I've bumped into another small
> bug. When pg_autovacuum goes to vacuum or analyze one of my tables it runs...
Also, has this been officially fixed? All I have heard so far is that
you commented out the check
On Fri, 2003-08-22 at 11:08, Jan Wieck wrote:
> > Another way to give autovacuum some hints would be to return some number
> > as commandtuples from vacuum. like the number of tuples actually
> > vacuumed. That together with the new number of reltuples in pg_class
> > will tell autovacuum how fr
On Fri, 2003-08-22 at 11:17, Shridhar Daithankar wrote:
> On 22 Aug 2003 at 11:03, Jan Wieck wrote:
> > That's why I think it needs one more pg_stat column to count the number
> > of vacuumed tuples. If one does
> >
> > tuples_updated + tuples_deleted - tuples_vacuumed
> >
> > he'll get app
On Fri, 2003-08-22 at 10:45, Tom Lane wrote:
> Jan Wieck <[EMAIL PROTECTED]> writes:
> Right. One big question mark in my mind about these "partial vacuum"
> proposals is whether they'd still allow adequate FSM information to be
> maintained. If VACUUM isn't looking at most of the pages, there's
This allows for mixed case schema names as well as tables.
Adam, can you please give this a test as you are the person who caught
the bug in the first place.
Thanks,
Matthew T. O'Connor
*** pg_autovacuum.c.orig 2003-09-10 23:13:51.95072 -0400
--- pg_autovacuum.c 2003-09-10 23:59:25
On Wed, 2003-09-10 at 12:03, Bruce Momjian wrote:
> Because MinGW/Msys doesn't come with flex/bison by default, I have added
> those derived files to the WIN32_DEV branch in CVS.
I'm confused. Right on the MinGW download page is a link for
bison-1.875.
---(end of broad
On Thu, 2003-09-11 at 15:02, Bruce Momjian wrote:
> Patch applied. You might want to look at pg_dump/dumputils.c::fmtId()
> for a function that does smart quoting.
OK, thanks.
---(end of broadcast)---
TIP 8: explain analyze is your friend
On Thu, 2003-09-11 at 08:12, Christopher Browne wrote:
> Something I am feeling a little suspicious of is that I haven't seen,
> in the logs, pg_autovacuum looking at pg_ tables.
>
> I know that if we don't periodically vacuum such system tables as
> pg_class, pg_attribute, pg_statistic, and pg_
On Thu, 2003-09-11 at 17:11, Tom Lane wrote:
> "Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> > I designed it that way. It was my understanding that all of the system
> > tables pg_class etc... are shared tables, available in all databases,
> > but
On Thu, 2003-09-11 at 18:25, Tom Lane wrote:
> BTW, I am not sure it is a good idea to suppress "redundant" vacuuming
> of shared tables in the first place. The trouble with doing so is that
> if you only vacuum pg_shadow through template1, then only template1 will
> ever have up-to-date statistic
On Thu, 2003-09-11 at 18:25, Tom Lane wrote:
> "Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> > hrm OK. Patch forthcoming
>
> BTW, I am not sure it is a good idea to suppress "redundant" vacuuming
> of shared tables in the first p
On Fri, 2003-09-12 at 09:35, Bruce Momjian wrote:
> Matthew T. O'Connor wrote:
> > I made a patch to fix this, but in testing it I noticed that the stats
> > system doesn't work on shared tables as I was expecting it too (as my
> > latest patch requires it too :-)
On Fri, 2003-09-12 at 12:46, Tom Lane wrote:
> How will it act with shared tables if the stats system isn't fixed?
> We may decide that tracking shared tables correctly will have to wait
> for 7.5.
The behavior in the patch will vacuum a shared table only from
template1, and only analyze from all
On Fri, 2003-09-12 at 13:06, Tom Lane wrote:
> > I can hardwire in something to hedge this off like setting the threshold
> > for shared tables much much lower than normal thresholds. I could also
> > do something more complicated and try to aggregate all the activity seen
> > by all the databases
On Tue, 2003-09-23 at 22:40, Greg Stark wrote:
> [But then I'm not a fan of treating pg_dump files as if they were backups.]
If you don't use pg_dump for backups what do you use? Stop the database
and copy the data directory? That is not a valid choice for most people.
-
On Fri, 2003-09-26 at 11:01, Tom Lane wrote:
> so it appears that cygwin's "echo" generates a different newline style
> than what got put into sql_features.txt. A possible way to fix this is
> to put the "\." line into sql_features.txt, but maybe there's a cleaner
> answer. Peter, any thoughts?
First, thanks for working on this. I hope to be helpful with the design
discussion and possibly some coding if I can find the time.
My initial reaction to this proposal is that it seems overly complex,
however I don't see a more elegant solution. I'm a bit concerned that
most users won't fig
Alvaro Herrera wrote:
Matthew T. O'Connor wrote:
Alvaro Herrera wrote:
pg_av_igroupmembers
groupid oid
month int
dom int
dow int
starttime timetz
endtime timetz
This seems to assume that the start and end time for an interval will b
Alvaro Herrera wrote:
I'd like to hear other people's opinions on Darcy Buskermolen proposal
to have a log table, on which we'd register what did we run, at what
time, how long did it last, how many tuples did it clean, etc. I feel
having it on the regular text log is useful but it's not good en
Alvaro Herrera wrote:
Matthew T. O'Connor wrote:
This still seems ambiguous to me, how would I handle a maintenance
window of Weekends from Friday at 8PM though Monday morning at 6AM? My
guess from what said is:
mon dom dow starttime endtime
null null6 20:00 null
null
Alvaro Herrera wrote:
This is how I think autovacuum should change with an eye towards being
able to run multiple vacuums simultaneously:
[snip details]
Does this raise some red flags? It seems straightforward enough to me;
I'll submit a patch implementing this, so that scheduling will conti
Alvaro Herrera wrote:
After staring at my previous notes for autovac scheduling, it has become
clear that this basics of it is not really going to work as specified.
So here is a more realistic plan:
[Snip Detailed Description]
How does this sound?
On first blush, I'm not sure I like this a
Alvaro Herrera wrote:
Matthew T. O'Connor wrote:
On first blush, I'm not sure I like this as it doesn't directly attack
the table starvation problem, and I think it could be a net loss of speed.
VACUUM is I/O bound, as such, just sending multiple vacuum commands at a
DB isn&
Alvaro Herrera wrote:
Ok, scratch that :-) Another round of braindumping below.
I still think this is solution in search of a problem. The main problem
we have right now is that hot tables can be starved from vacuum. Most
of this proposal doesn't touch that. I would like to see that probl
Jim C. Nasby wrote:
On Wed, Feb 21, 2007 at 05:40:53PM -0500, Matthew T. O'Connor wrote:
My Proposal: If we require admins to identify hot tables tables, then:
1) Launcher fires-off a worker1 into database X.
2) worker1 deals with "hot" tables first, then regular tabl
Jim C. Nasby wrote:
On Thu, Feb 22, 2007 at 09:32:57AM -0500, Matthew T. O'Connor wrote:
So the heuristic would be:
* Launcher fires off workers into a database at a given interval
(perhaps configurable?)
* Each worker works on tables in size order.
* If a worker ever catches up
Alvaro Herrera wrote:
Jim C. Nasby wrote:
That's why I'm thinking it would be best to keep the maximum size of
stuff for the second worker small. It probably also makes sense to tie
it to time and not size, since the key factor is that you want it to hit
the high-update tables every X number of
1 - 100 of 312 matches
Mail list logo
