Alvaro Herrera wrote:
Warren Turkal wrote:
On Saturday 24 February 2007 15:18, Alvaro Herrera wrote:
Keep in mind that the repository as converted by Josh, above, is
strangely corrupted in weird and unpredictable ways.
Would you care to elaborate on that statement? I'd like to check my
convert
Hi
We are developing a new feature for vacuum, here is a brief overview
about it.
Introduction
A) What is it?
This feature enables vacuum has resumable capability. Vacuum can
remembers the point it stops, then resumes interrupted vacuum operation
from the point next time.
The SQL
Hi,
Andrew Dunstan wrote:
O.k. everyone pay attention, I am about to agree with Greg! ;)
Greg are their tools to migrate CVS to monotone or whatever your
favorite is? The reason I ask is that I migrate the CVS to SVN every 4
hours I think it is and it isn't perfect.
monotone ships it's own cv
Hi,
Matthew D. Fuller wrote:
I would say that a far greater contributor in practice would simply be
frequency. If you diverge on your significant feature for 6 months,
then try to merge in upstream changes from the main dev, you will be
in hell no matter what merge algorithm you use.
Do you h
Hi,
Tom Lane wrote:
Yah know, the one bit of these pitches that always sounds like pure
snake oil is the claim that they offer some kind of mechanical solution
to merge conflicts. AFAICS that has nothing to do with the SCMS in use
and everything to do with whether your "diff" command is AI-comp
Hi,
Warren Turkal wrote:
Cvs2svn seems to make as much sense of CVS data as possible. The only real
problem I have seen is with regard to the malformed files I mentioned
earlier.
cvs2svn (1.x) still heavily relies on timestamps, which is certainly
correct in most cases. But they are switchin
On Mon, 2007-02-26 at 18:21 +0900, Galy Lee wrote:
> This implementation accepts stop request at *blocks level* in step 1-4.
>
> D) How to stop and resume
>
> - stop:
>
> When vacuum stop in step 1-4, vacuum perform following things:
> vacuum saves dead tuple list, the heap block number
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, Feb 26, 2007 at 06:21:50PM +0900, Galy Lee wrote:
> Hi
>
> We are developing a new feature for vacuum, here is a brief overview
> about it.
[...]
> Concurrent vacuum mainly has the following steps to vacuum a table:
>
> 1. scan heap to co
Hi,
How are you doing with the bitmap indexes?
I've been trying to get my head around the patch a couple of times to
add the vacuum support, but no matter how simple I try to keep it, I
just always seem to get stuck.
It looks like vacuum support would need:
- something similar to read_words
Joshua D. Drake wrote:
> Christopher Browne wrote:
> > A long time ago, in a galaxy far, far away, [EMAIL PROTECTED] (Hideyuki
> > Kawashima) wrote:
> >> I appreciate your great suggestion!
> >> It is great honor for me if Sigres will be merged to PostgreSQL.
> >> Since the changes of Sigres from
On Mon, Feb 26, 2007 at 11:07:01AM +0100, Markus Schiltknecht wrote:
> Tom Lane wrote:
> >Yah know, the one bit of these pitches that always sounds like pure
> >snake oil is the claim that they offer some kind of mechanical solution
> >to merge conflicts. AFAICS that has nothing to do with the SCM
Hi,
[EMAIL PROTECTED] wrote:
I'll have to try kdiff3 - but the "merge" command, although it often works,
I strongly dislike when it marks up the lines as "there was a conflict here"
and gives you three files in the directory to choose to start from. This is
far too manual, which invites mistakes
I installed NPGSQL for connectivity with VB.NET but noticed it's performance
slow as compared with ODBC driver. Why?
--
View this message in context:
http://www.nabble.com/NPGSQL-ODBC-performance-tf3293489.html#a9160834
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
---
RPK wrote:
I installed NPGSQL for connectivity with VB.NET but noticed it's performance
slow as compared with ODBC driver. Why?
As I told you two days ago, this is the wrong list for these questions.
You need to ask NPGSQL questions on its mailing lists, not here. The
core postgresql hacke
Jonah H. Harris wrote:
> On 2/23/07, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
> > A good example of the wrong way to do it is the Full Disjunctions
> > project. Great idea, Great project, not bitrot and hard space because it
> > hasn't been touched or maintained sense release.
>
> Don't get me s
I realized this proposal has been withdrawn, but the fact the proposal
even illicited comments exploring it requires me to comment.
Folks, how can we entertain ideas that would break SELECT * and
no-column-list INSERTs for a small performance boost? If there was no
other way to get the performan
On 2/23/07, Tom Lane <[EMAIL PROTECTED]> wrote:
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> On friday we upgraded a critical backend server to postgresql 8.2
> running on fedora core 4.
Umm ... why that particular choice of OS? Red Hat dropped update
support for FC4 some time ago, and AFAIK
Hi,
On Mon, 2007-02-26 at 08:24 -0500, Merlin Moncure wrote:
> we tried update to the latest via yum update with no help.
As Tom stated, FC4 is no more supported; therefore you won't be able to
get newer kernel via yum.
> as promised, here is the best photo of the panic we could get:
> http://i
Tom Lane wrote:
> Warren Turkal <[EMAIL PROTECTED]> writes:
>> On Saturday 24 February 2007 23:11, Tom Lane wrote:
>>> I also tend to think that a conversion will be easier in a year or two
>>> than it is today --- the problems noted upthread are certainly a
>>> heads-up that cvs2svn is not yet as
Bruce Momjian wrote:
Folks, how can we entertain ideas that would break SELECT * and
no-column-list INSERTs for a small performance boost? If there was no
other way to get the performance boost, and the features was rarely
used, we might consider such a change, but neither is true in this case.
Ci vogliono solo 30 secondi del vostro tempo...per fare qualcosa di
buono.
Un cittadino italiano ha finalmente deciso che gli fa troppo male
respirare le polveri sottili e vedere persone a cui vuole bene morire
di cancro intorno a sé per il benessere delle multinazionali
petrolifere e ha chies
>> I imagine the problems are caused by manual mangling of the files in the
>> early days, like the perl5 dir stuff you found.
>
> Hmm, if you only checked using the Trac interface, maybe this is an
> issue with re-creating the SVN repo.
>
> Joshua, do you run "trac-admin /path/to/trac/env resyn
SORRY.
--
View this message in context:
http://www.nabble.com/NPGSQL-ODBC-performance-tf3293489.html#a9162156
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
---(end of broadcast)---
TIP 9: In versions below 8.0, the planne
Andrew Dunstan wrote:
> Bruce Momjian wrote:
> >
> > Folks, how can we entertain ideas that would break SELECT * and
> > no-column-list INSERTs for a small performance boost? If there was no
> > other way to get the performance boost, and the features was rarely
> > used, we might consider such a
Warren Turkal wrote:
> On Saturday 24 February 2007 16:47, Chad Wagner wrote:
> > head pgsql/src/interfaces/perl5/Attic/test.pl.oldstyle,v
> > head ? ?1.3;
> > access;
> > symbols
> > ? ? ? ? Release-1-6-0:1.1.1.1
> > ? ? ? ? creation:1.1.1.1
> > ? ? ? ? creation:1.1.1; ? ?<<< What the heck happene
> In Simon's defense, I think we need to feel free to brainstorm a bit,
> and propose things that might seem odd. There are plenty of cool heads
> around to shoot down bad ideas, but we'll only make progress by
> cherry-picking the good ideas. If one out of ten of my ideas is useful I
> think I'm
Warren Turkal wrote:
> On Saturday 24 February 2007 16:47, Chad Wagner wrote:
> > head pgsql/src/interfaces/perl5/Attic/test.pl.oldstyle,v
> > head ? ?1.3;
> > access;
> > symbols
> > ? ? ? ? Release-1-6-0:1.1.1.1
> > ? ? ? ? creation:1.1.1.1
> > ? ? ? ? creation:1.1.1; ? ?<<< What the heck happene
Warren Turkal wrote:
> On Sunday 25 February 2007 23:23, Tom Lane wrote:
> > It was mentioned upthread that Josh has seen repeated problems with his
> > conversions.
>
> I am manually inspecting the diff between CVS tag REL_8_1_0 and SVN tag
> tags/REL_8_1_0/pgsql, and I am not finding any differ
On Monday 26 February 2007 10:13, Bruce Momjian wrote:
> Done. Any other problems?
I don't see the fix in the rsync archive. When will it show up there? For
reference, the changes were needed in the following files in
cvsroot/pgsql/src/interfaces/perl5/Attic:
* ApachePg.pl,v
* test.pl.newstyle,
On Mon, 2007-02-26 at 11:20 -0500, Bruce Momjian wrote:
> I realized this proposal has been withdrawn, but the fact the proposal
> even illicited comments exploring it requires me to comment.
>
> Folks, how can we entertain ideas that would break SELECT * and
> no-column-list INSERTs for a small
On Monday 26 February 2007 08:04, Markus Schiltknecht wrote:
> Others you might want to try:
>
> - meld (in python, IMO worse than kdiff3)
> - xxdiff (I've never really used that one, but other monotone hackers
> seem to like it as well)
A couple more options:
* kompare (this one is pretty)
*
Simon Riggs wrote:
> On Mon, 2007-02-26 at 11:20 -0500, Bruce Momjian wrote:
>
> > I realized this proposal has been withdrawn, but the fact the proposal
> > even illicited comments exploring it requires me to comment.
> >
> > Folks, how can we entertain ideas that would break SELECT * and
> > no
Warren Turkal wrote:
> On Monday 26 February 2007 10:13, Bruce Momjian wrote:
> > Done. Any other problems?
>
> I don't see the fix in the rsync archive. When will it show up there? For
About an hour.
> reference, the changes were needed in the following files in
> cvsroot/pgsql/src/interfaces
On 12/19/06, ITAGAKI Takahiro <[EMAIL PROTECTED]> wrote:
"Takayuki Tsunakawa" <[EMAIL PROTECTED]> wrote:
> I performed some simple tests, and I'll show the results below.
> (1) The default case
> 235 80 226 77 240
> (2) No write case
> 242 250 244 253 280
> (3) No checkpoint case
> 229
Joshua D. Drake wrote:
>>> I imagine the problems are caused by manual mangling of the files in the
>>> early days, like the perl5 dir stuff you found.
>> Hmm, if you only checked using the Trac interface, maybe this is an
>> issue with re-creating the SVN repo.
>>
>> Joshua, do you run "trac-admin
[EMAIL PROTECTED] writes:
> WARNING: I don't really know what I'm talking about -- but considering
> that vaccuming a large table across several "maintainance windows" is
> one of the envisioned scenarios, it might make sense to try to update
> the statistics (i.e. to do partially step 7) on each p
On Monday 26 February 2007 10:13, Bruce Momjian wrote:
> Done. Any other problems?
Only figuring out the encoding issues with cvs.
Thanks,
wt
--
Warren Turkal (w00t)
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
On Mon, 2007-02-26 at 13:02 -0500, Bruce Momjian wrote:
> Simon Riggs wrote:
> > On Mon, 2007-02-26 at 11:20 -0500, Bruce Momjian wrote:
> >
> > > I realized this proposal has been withdrawn, but the fact the proposal
> > > even illicited comments exploring it requires me to comment.
> > >
> > >
On Monday 26 February 2007 10:04, Markus Schiltknecht wrote:
> Hi,
>
> [EMAIL PROTECTED] wrote:
> > I'll have to try kdiff3 - but the "merge" command, although it often
> > works, I strongly dislike when it marks up the lines as "there was a
> > conflict here" and gives you three files in the direc
Trying to compile 8.2.3 with VC 7.10.3077 (2003) on Win32, I get the
following error:
mypath\postgresql-8.2.3\src\include\c.h(88) : fatal
error C1083: Cannot open include file: 'pg_config_os.h': No such file or
directory
Is this a known issue? (is there a patch available?)
thanks.
jeff
Joshua D. Drake wrote:
> Joshua D. Drake wrote:
> >>> I imagine the problems are caused by manual mangling of the files in the
> >>> early days, like the perl5 dir stuff you found.
> >> Hmm, if you only checked using the Trac interface, maybe this is an
> >> issue with re-creating the SVN repo.
> >
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> The order of the columns is *arbitrary* in relational theory;
SQL is very far from being relational theory...
regards, tom lane
---(end of broadcast)---
TIP 7: You can help support
Robert Treat wrote:
FWIW ClearCase also offers a command line version of its merge tool, where it
shows three columns (a la diff --side-by-side) and allows you to pick which
column you want to merge in (repo, change1, or change2 for example). It's a
nice attempt at doing it on the command li
Alvaro Herrera wrote:
> Joshua D. Drake wrote:
>> Joshua D. Drake wrote:
> I imagine the problems are caused by manual mangling of the files in the
> early days, like the perl5 dir stuff you found.
Hmm, if you only checked using the Trac interface, maybe this is an
issue with re-c
Simon Riggs wrote:
> > > wondered why that proposal had been overlooked, so I started a separate
> > > thread to ensure that the idea was discussed. That seems very similar to
> > > many of your own posts.
> >
> > True, but usually I don't see the breakage.
>
> Sorry, I just meant you summarise i
Please ignore this question. I was compiling with the
/src/interfaces/libpq/win32.mak file. I later noticed that the proper
way to compile libpq is to use the /src/win32.mak file.
thanks.
jeff
Jeff McKenna wrote:
Trying to compile 8.2.3 with VC 7.10.3077 (2003) on Win32, I get the
follo
Bruce,
> True, but usually I don't see the breakage. What concerned me is you
> saw some of the breakage, but still went ahead with the proposal.
That's completely unfair, Bruce. This is a *discussion list*, and hackers are
free to propose and discuss even far-out improbable ideas in the hopes
Gottfried,
> Just wondering after reading so many mails from Hackers List.(its 2.15 AM
> now!!) Is there anybody working on something to create a DB from
> a) The TODO list http://www.postgresql.org/docs/faqs.TODO.html
> b) The sourcecode of PostgreSQL
> c) The relevant Mailings from the developer
Josh Berkus wrote:
For my part, I continue to the interested in this proposal and would like to
see some performance benchmarks on it. If there is enough performance gain,
I think it would be possible to implement a "logical" order which was
different from the "physical" order. Such a feature
On Feb 25, 9:34 am, [EMAIL PROTECTED] (Andrew Dunstan) wrote:
> Phani Kishore wrote:
>
> > hi !
>
> > i think u people could probably help me i how to query the
> > pgsql/postgis from google maps api to display the markers on the
> > google maps which are stored in the postgis database.
> > Phani K
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 seconds.
>
> If
On 2/26/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
Jonah, I have no idea what "fault" you are trying to blame on the
community in the above statement. The author didn't discuss the idea
with the community before spending months on it so we have no obligation
to accept it in the core.
You're
The next Summer of Code is just around the corner.
Last year, we had 46 submissions and seven we accepted. Out of the SoC we got
two ongoing contributors, several good patches, two code refactors and even
an employee for a PostgreSQL company. I'd like to see us do the same this
year!
Therefo
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
On Monday 26 February 2007 14:57, Andrew Dunstan wrote:
> Robert Treat wrote:
> > FWIW ClearCase also offers a command line version of its merge tool,
> > where it shows three columns (a la diff --side-by-side) and allows you to
> > pick which column you want to merge in (repo, change1, or change2
On Sunday 25 February 2007 01:11, Tom Lane wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> > Lastly, who really cares? Does it really matter? No. I would much rather
> > Warren (if he has the skills) put some effort into Patch Review.
>
> That's pretty much the bottom line. CVS is not so
Josh Berkus wrote:
The next Summer of Code is just around the corner.
Last year, we had 46 submissions and seven we accepted. Out of the SoC we got
two ongoing contributors, several good patches, two code refactors and even
an employee for a PostgreSQL company. I'd like to see us do the same
Jonah H. Harris wrote:
> On 2/26/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
>> Jonah, I have no idea what "fault" you are trying to blame on the
>> community in the above statement. The author didn't discuss the idea
>> with the community before spending months on it so we have no obligation
>>
On Mon, 2007-02-26 at 09:44 -0500, Bruce Momjian wrote:
> Joshua D. Drake wrote:
> > Christopher Browne wrote:
> > > A long time ago, in a galaxy far, far away, [EMAIL PROTECTED] (Hideyuki
> > > Kawashima) wrote:
> > >> I appreciate your great suggestion!
> > >> It is great honor for me if Sigres
On Monday 26 February 2007 13:50, Robert Treat wrote:
> It's worth keeping in mind that one of the primary reasons we don't have a
> different usage pattern is because CVS makes such a thing painful. Given
> how much of development is done now, I have a feeling that the community
> might well adop
I am a little concerned about a log_* setting that is INFO. I understand
why you used INFO (for log_min_error_messages), but INFO is inconsistent
with the log* prefix, and by default INFO doesn't appear in the log
file.
So, by default, the INFO is going to go to the user terminal, and not to
the
On Mon, 2007-02-26 at 13:34 -0500, Bruce Momjian wrote:
> I am a little concerned about a log_* setting that is INFO. I understand
> why you used INFO (for log_min_error_messages), but INFO is inconsistent
> with the log* prefix, and by default INFO doesn't appear in the log
> file.
Yeh, LOG woul
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> Yeh, LOG would be most appropriate, but thats not possible.
You have not given any good reason for that.
> log_min_messages allows only DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1,
> INFO, NOTICE and WARNING for non-error states.
I don't think you understan
On Mon, 2007-02-26 at 14:11 -0500, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > Yeh, LOG would be most appropriate, but thats not possible.
>
> You have not given any good reason for that.
The idea of the patch is that it generates a log message which then
invokes log_min_error
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> The idea of the patch is that it generates a log message which then
> invokes log_min_error_statement so that the SQL statement is displayed.
> LOG is not on the list of options there, otherwise I would use it.
As I said, you don't understand how the log
On Mon, 2007-02-26 at 14:28 -0500, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > The idea of the patch is that it generates a log message which then
> > invokes log_min_error_statement so that the SQL statement is displayed.
> > LOG is not on the list of options there, otherwise I
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> On Mon, 2007-02-26 at 14:28 -0500, Tom Lane wrote:
>> "Simon Riggs" <[EMAIL PROTECTED]> writes:
>>> The idea of the patch is that it generates a log message which then
>>> invokes log_min_error_statement so that the SQL statement is displayed.
>>> LOG is
On Mon, 2007-02-26 at 14:52 -0500, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > On Mon, 2007-02-26 at 14:28 -0500, Tom Lane wrote:
> >> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> >>> The idea of the patch is that it generates a log message which then
> >>> invokes log_min_error_
Simon Riggs wrote:
> On Mon, 2007-02-26 at 13:34 -0500, Bruce Momjian wrote:
>
> > I am a little concerned about a log_* setting that is INFO. I understand
> > why you used INFO (for log_min_error_messages), but INFO is inconsistent
> > with the log* prefix, and by default INFO doesn't appear in t
Bruce Momjian <[EMAIL PROTECTED]> writes:
> This is not the first GUC that has needed this.
Exactly. I think that we simply made a mistake in the initial
implementation of log_min_error_statement: we failed to think about
whether it should use client or server priority ordering, and the
easy-to-c
Andrew,
> Is there a list of projects? Or can we suggest some?
Suggest away, please!
I'm going to update the website soon, would appreciate new content.
--
--Josh
Josh Berkus
PostgreSQL @ Sun
San Francisco
---(end of broadcast)---
TIP 2: Don't
On 2/26/07, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
Josh Berkus wrote:
> The next Summer of Code is just around the corner.
>
> Last year, we had 46 submissions and seven we accepted. Out of the SoC we got
> two ongoing contributors, several good patches, two code refactors and even
> an emplo
Josh Berkus wrote:
Andrew,
Is there a list of projects? Or can we suggest some?
Suggest away, please!
I'm going to update the website soon, would appreciate new content.
here are a few ideas to be going on with (none of these are new):
buildfarm:
1. Buildfarm web app: is in u
On 2/26/07, Josh Berkus wrote:
Andrew,
> Is there a list of projects? Or can we suggest some?
Suggest away, please!
I'm going to update the website soon, would appreciate new content.
I can also volunteer to mentor continuing work on a TPC-E kit, for C
stored procedures and improved results
On Monday 26 February 2007 14:22, Andrew Dunstan wrote:
> Is there a list of projects? Or can we suggest some?
Temporal database support
* base data types
- verify current for ISO compliance (timestamp, interval)
- implement period datatype
* operators for those datatypes
* add support for val
Proposal: Implement a new option for COMMIT, for enhancing performance,
providing a MySQL-like trade-off between performance and robustness for
*only* those that want it.
COMMIT NOWAIT
This form of COMMIT will *not* perform XLogFlush(), but will rely on a
special background process to per
Warren Turkal wrote:
On Monday 26 February 2007 14:22, Andrew Dunstan wrote:
Is there a list of projects? Or can we suggest some?
Temporal database support
* base data types
- verify current for ISO compliance (timestamp, interval)
- implement period datatype
* operators for those
> Why do we want this?? Because some apps have *lots* of data and many
> really don't care whether they lose a few records. Honestly, I've met
> people that want this, even after 2 hours of discussion and
> understanding. Plus probably lots of MySQLers also.
Most users will take speed over data l
On Mon, 26 Feb 2007, Heikki Linnakangas wrote:
> Hi,
>
> How are you doing with the bitmap indexes?
I need to send of a patch fixing the last bug you pointed out. The code
needs a merge of HEAD.
>
> I've been trying to get my head around the patch a couple of times to
> add the vacuum support, b
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> Reading through the design, I see the following
> - bgwriter performs XLogWrite, not each backend
> - WAL fsync is only performed when WAL file fills
> - no checkpoints are performed until shutdown
> Not checkpointing at all is not a good plan, since th
Matthew T. O'Connor wrote:
> Alvaro Herrera wrote:
> >The second mode is the "hot table worker" mode, enabled when the worker
> >detects that there's already a worker in the database. In this mode,
> >the worker is limited to those tables that can be vacuumed in less than
> >autovacuum_naptime, s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Could you also please share your thoughts on what would be a good
student profile- for instance, how much theoretical background and
practical experience, for working on a SoC project?
Demian
> The next Summer of Code is just around the corner.
>
>
Alvaro Herrera wrote:
Matthew T. O'Connor wrote:
How can you determine what tables can be vacuumed within
autovacuum_naptime?
My assumption is that
pg_class.relpages * vacuum_cost_page_miss * vacuum_cost_delay = time to vacuum
This is of course not the reality, because the delay is not how lo
Simon Riggs wrote:
Proposal: Implement a new option for COMMIT, for enhancing performance,
providing a MySQL-like trade-off between performance and robustness for
*only* those that want it.
COMMIT NOWAIT
This form of COMMIT will *not* perform XLogFlush(), but will rely on a
special back
Demian,
> Could you also please share your thoughts on what would be a good
> student profile- for instance, how much theoretical background and
> practical experience, for working on a SoC project?
Well, it shouldn't be the student's first year writing code. Basically,
they're committing to de
On Mon, 2007-02-26 at 23:25 +, Richard Huxton wrote:
> Simon Riggs wrote:
> > Proposal: Implement a new option for COMMIT, for enhancing performance,
> > providing a MySQL-like trade-off between performance and robustness for
> > *only* those that want it.
> >
> > COMMIT NOWAIT
> >
>
Matthew T. O'Connor wrote:
> Alvaro Herrera wrote:
> >Matthew T. O'Connor wrote:
> >>How can you determine what tables can be vacuumed within
> >>autovacuum_naptime?
> >
> >My assumption is that
> >pg_class.relpages * vacuum_cost_page_miss * vacuum_cost_delay = time to
> >vacuum
> >
> >This is of
Simon Riggs wrote:
> The interesting point is you can have a huge data grinding app, yet with
> other tables alongside that hold more important data. In that scenario,
> 90% of the data would be COMMIT NOWAIT, whilst the small important data
> is safe.
Does this means that the regular COMMIT is s
On Feb 26, 2007, at 18:58 , Simon Riggs wrote:
On Mon, 2007-02-26 at 23:25 +, Richard Huxton wrote:
Simon Riggs wrote:
Proposal: Implement a new option for COMMIT, for enhancing
performance,
providing a MySQL-like trade-off between performance and
robustness for
*only* those that want
"Inaam Rana" <[EMAIL PROTECTED]> wrote:
> Did you had a chance to look into this any further? We, at EnterpriseDB,
> have done some testing on this patch (dbt2 runs) and it looks like we are
> getting the desired results, particularly so when we spread out both sync
> and write phases.
Thank you
getting back on topic (ahem), florian: are you comfortable going ahead
with this? is there anything you need help with?
merlin
---(end of broadcast)---
TIP 6: explain analyze is your friend
Itagaki,
> Thank you for testing! Yes, I'm cleaning the patch. I changed
> configuration parameters to delay each phase in checkpoints from setting
> absolute times (checkpoint_xxx_duration) to setting relative to
> checkpoint_timeout (checkpoint_xxx_percent). Delay factors strongly
> depend on to
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Well, here's a question. Given the recent discussion re full
> disjunction, I'd like to know what sort of commitment we are going to
> give people who work on proposed projects.
Um, if you mean are we going to promise to accept a patch in advance of
s
Alvaro Herrera wrote:
Matthew T. O'Connor wrote:
I'm not sure how pg_class.relpages is maintained but what happens to a
bloated table? For example, a 100 row table that is constantly updated
and hasn't been vacuumed in a while (say the admin disabled autovacuum
for a while), now that small 10
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Matthew T. O'Connor wrote:
>> I'm not sure it's a good idea to tie this to the vacuum cost delay
>> settings either, so let me as you this, how is this better than just
>> allowing the admin to set a new GUC variable like
>> autovacuum_hot_table_size_
Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
>> Well, here's a question. Given the recent discussion re full
>> disjunction, I'd like to know what sort of commitment we are going to
>> give people who work on proposed projects.
>
> Um, if you mean are we going to promise to accep
Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
Matthew T. O'Connor wrote:
I'm not sure it's a good idea to tie this to the vacuum cost delay
settings either, so let me as you this, how is this better than just
allowing the admin to set a new GUC variable like
autovacuum_hot_table_
On Mon, Feb 26, 2007 at 09:22:42PM -0500, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Matthew T. O'Connor wrote:
> >> I'm not sure it's a good idea to tie this to the vacuum cost delay
> >> settings either, so let me as you this, how is this better than just
> >> allowing the
On Mon, Feb 26, 2007 at 08:11:44PM -0300, Alvaro Herrera wrote:
> Matthew T. O'Connor wrote:
> > Alvaro Herrera wrote:
>
> > >The second mode is the "hot table worker" mode, enabled when the worker
> > >detects that there's already a worker in the database. In this mode,
> > >the worker is limite
On Mon, 2007-02-26 at 22:56 +, Simon Riggs wrote:
> Proposal: Implement a new option for COMMIT, for enhancing performance,
> providing a MySQL-like trade-off between performance and robustness for
> *only* those that want it.
>
> COMMIT NOWAIT
>
> This form of COMMIT will *not* perfo
1 - 100 of 149 matches
Mail list logo
