Alvaro Herrera wrote:
Tom Lane escribió:
Gregory Stark [EMAIL PROTECTED] writes:
The entire target market for such a thing is DBAs stuck on hosted databases
which don't have shell access to their machines. Perhaps the overlap between
that and the people who can write a server-side module
Am Monday, 18. August 2008 schrieb Josh Berkus:
Right now, if you want to survey
your databases, tables, approx disk space, query activity, etc., you can
do that all through port 5432. You can't manage most of your server
settings that way, and definitely can't manage the *persistent*
Am Monday, 18. August 2008 schrieb Tom Lane:
The impression I get every time this comes up is that various people
have different problems they want to solve that (they think) require
redesign of the way GUC works. Those complicated solutions arise from
attempting to satisfy N different
What I'm interested in is auto-tuning, not necessarily overhauling GUCS,
which happens to be the subject of this thread :-)
Having done a SELECT * FROM pg_settings, all the information you need seems
to be there...
Maybe I'm being over-simplistic here, but the important bit is knowing how
you
On Aug 18, 2008, at 1:05 AM, Magnus Hagander wrote:
Josh Berkus wrote:
Steve,
First pass is done. Needs a little cleanup before sharing. I spent a
fair while down OS-specific-hardware-queries rathole, but I'm
better now.
Gods, I hope you gave up on that. You want to use SIGAR or
Steve Atkins wrote:
On Aug 18, 2008, at 1:05 AM, Magnus Hagander wrote:
Josh Berkus wrote:
Steve,
First pass is done. Needs a little cleanup before sharing. I spent a
fair while down OS-specific-hardware-queries rathole, but I'm better
now.
Gods, I hope you gave up on that. You want
On Mon, 18 Aug 2008, Michael Nacos wrote:
Having done a SELECT * FROM pg_settings, all the information you need
seems to be there...
See http://archives.postgresql.org/pgsql-hackers/2008-06/msg00209.php You
sound like you're at rung 2 on the tool author ladder I describe there,
still
Greg Smith [EMAIL PROTECTED] writes:
On Mon, 18 Aug 2008, Michael Nacos wrote:
Having done a SELECT * FROM pg_settings, all the information you need seems
to be there...
See http://archives.postgresql.org/pgsql-hackers/2008-06/msg00209.php You
sound
like you're at rung 2 on the tool
Greg,
The entire target market for such a thing is DBAs stuck on hosted
databases which don't have shell access to their machines.
That's incorrect. The main reason for having a port-based API (such as the
SQL command line) for managing your server is that it makes it much easier
to manage
Gregory Stark [EMAIL PROTECTED] writes:
The entire target market for such a thing is DBAs stuck on hosted databases
which don't have shell access to their machines. Perhaps the overlap between
that and the people who can write a server-side module which dumps out a
config file according to
Josh Berkus [EMAIL PROTECTED] writes:
Greg,
The entire target market for such a thing is DBAs stuck on hosted
databases which don't have shell access to their machines.
That's incorrect. The main reason for having a port-based API (such as the
SQL command line) for managing your server
Greg,
The main problem that I've seen described is what I mentioned before:
allowing adjusting the postgresql.conf GUC settings by remote users who
don't have shell access.
Oh, ok. I think we're in agreement, though. I don't think that's the
*1st* problem to be solved, but it's definitely
On Mon, Aug 18, 2008 at 8:51 PM, Gregory Stark [EMAIL PROTECTED] wrote:
The main problem that I've seen described is what I mentioned before: allowing
adjusting the postgresql.conf GUC settings by remote users who don't have
shell access.
Which pgAdmin has done perfectly well for years, as
On Mon, 18 Aug 2008, Gregory Stark wrote:
Because coping with free-form user-edited text is a losing game. People
don't consider it because it's a dead-end.
Right, that's impossible technology to build, which is why I had to plan
all these screen shots showing tools that handle that easily
Dave Page wrote:
On Mon, Aug 18, 2008 at 8:51 PM, Gregory Stark [EMAIL PROTECTED] wrote:
The main problem that I've seen described is what I mentioned before:
allowing
adjusting the postgresql.conf GUC settings by remote users who don't have
shell access.
Which pgAdmin has done perfectly
On 8/18/08, Magnus Hagander [EMAIL PROTECTED] wrote:
Dave Page wrote:
On Mon, Aug 18, 2008 at 8:51 PM, Gregory Stark [EMAIL PROTECTED]
wrote:
The main problem that I've seen described is what I mentioned before:
allowing
adjusting the postgresql.conf GUC settings by remote users who don't
Tom Lane escribió:
Gregory Stark [EMAIL PROTECTED] writes:
The entire target market for such a thing is DBAs stuck on hosted databases
which don't have shell access to their machines. Perhaps the overlap between
that and the people who can write a server-side module which dumps out a
On Wed, 13 Aug 2008, Michael Nacos wrote:
Hi there... Configuration autotuning is something I am really interested in.
I have seen this page: http://wiki.postgresql.org/wiki/GUCS_Overhaul and
a couple of emails mentioning this, so I wanted to ask is someone already
on it? If yes, I'd like to
Greg Smith [EMAIL PROTECTED] writes:
Josh Berkus and I have been exchanging some ideas for the GUC internals
overhaul and had a quick discussion about that in person last month.
We've been gravitating toward putting all the extra information we'd like
to push into there in an extra catalog
On Sun, 17 Aug 2008, Tom Lane wrote:
What we have now was named Grand Unified Configuration for a reason:
it centralized the handling of what had been a mess of different things
configured in different ways. I'm not eager to go backwards on that.
No need to change anything related to how the
On Aug 17, 2008, at 1:48 PM, Greg Smith wrote:
On Wed, 13 Aug 2008, Michael Nacos wrote:
Hi there... Configuration autotuning is something I am really
interested in.
I have seen this page: http://wiki.postgresql.org/wiki/
GUCS_Overhaul and
a couple of emails mentioning this, so I wanted to
Steve,
First pass is done. Needs a little cleanup before sharing. I spent a
fair while down OS-specific-hardware-queries rathole, but I'm better now.
Gods, I hope you gave up on that. You want to use SIGAR or something.
--Josh
--
Sent via pgsql-hackers mailing list
Hi there... Configuration autotuning is something I am really interested in.
I have seen this page: http://wiki.postgresql.org/wiki/GUCS_Overhaul and
a couple of emails mentioning this, so I wanted to ask is someone already
on it? If yes, I'd like to contribute.
Ideally, an external little app
Added to TODO:
o Add external tool to auto-tune some postgresql.conf parameters
http://archives.postgresql.org/pgsql-hackers/2008-06/msg0.php
---
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED]
Greg Smith wrote:
On Thu, 5 Jun 2008, Magnus Hagander wrote:
We really need a proper API for it, and the stuff in pgAdmin isn't
even enough to base one on.
I would be curious to hear your opinion on whether the GUC overhaul
discussed in this thread is a useful precursor to building such a
On Wednesday 11 June 2008 16:54:23 Bruce Momjian wrote:
Dave Page wrote:
On Wed, Jun 11, 2008 at 6:56 PM, Bruce Momjian [EMAIL PROTECTED] wrote:
Dave Page wrote:
On Mon, Jun 2, 2008 at 5:46 AM, Joshua D. Drake [EMAIL PROTECTED]
wrote:
pg_ctl -D data check?
I would +1 that.
Robert Treat wrote:
On Wednesday 11 June 2008 16:54:23 Bruce Momjian wrote:
Dave Page wrote:
On Wed, Jun 11, 2008 at 6:56 PM, Bruce Momjian [EMAIL PROTECTED] wrote:
Dave Page wrote:
On Mon, Jun 2, 2008 at 5:46 AM, Joshua D. Drake [EMAIL PROTECTED]
wrote:
pg_ctl -D data check?
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Also, I'd actually assert that 10 seems to be perfectly adequate for
the majority of users. That is, the number of users where I've
recommended increasing d_s_t for the whole database is smaller than the
number where I don't, and of course
Greg Sabino Mullane [EMAIL PROTECTED] writes:
The orders of magnitude speed up of certain queries when the d_s_t goes
above 98 is what spawned my original thread proposing a change to 100:
http://markmail.org/message/tun3a3juxlsyjbsw
That was a pretty special case (LIKE/regex estimation), and
Greg Sabino Mullane [EMAIL PROTECTED] writes:
Also, I'd actually assert that 10 seems to be perfectly adequate for
the majority of users. That is, the number of users where I've
recommended increasing d_s_t for the whole database is smaller than the
number where I don't, and of course we
Bruce,
I am concerned that each wizzard is going to have to duplicate the same
logic each time, and adjust to release-based changes.
I think that's a feature, not a bug. Right now, I'm not at all convinced that
my algorithms for setting the various major dials are great (I just think
that
Josh Berkus wrote:
Bruce,
I am concerned that each wizard is going to have to duplicate the same
logic each time, and adjust to release-based changes.
I think that's a feature, not a bug. Right now, I'm not at all convinced
that
my algorithms for setting the various major dials are
Bruce,
I am thinking a web-based wizard would make the most sense.
I'd prefer command-line, so that people could run it on their own servers.
For one thing, we need to generate at least two files on many platforms; a
postgresql.conf and a sysctl.
--
Josh Berkus
PostgreSQL @ Sun
San
Josh Berkus wrote:
Bruce,
I am thinking a web-based wizard would make the most sense.
I'd prefer command-line, so that people could run it on their own servers.
For one thing, we need to generate at least two files on many platforms; a
postgresql.conf and a sysctl.
They can just
On Jun 12, 2008, at 11:21 AM, Bruce Momjian wrote:
Josh Berkus wrote:
Bruce,
I am concerned that each wizard is going to have to duplicate the
same
logic each time, and adjust to release-based changes.
I think that's a feature, not a bug. Right now, I'm not at all
convinced that
my
On Thu, 12 Jun 2008, Bruce Momjian wrote:
I am thinking a web-based wizard would make the most sense.
I have not a single customer I work with who could use an external
web-based wizard. Way too many companies have privacy policy restrictions
that nobody dare cross by giving out any info
On Jun 11, 2008, at 9:34 PM, Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
The idea has a fundamental logical flaw, which is that it's not
clear
which parameter wins if the user changes both.
Yes, you could get into problems by having
Decibel! [EMAIL PROTECTED] writes:
On Jun 11, 2008, at 9:34 PM, Bruce Momjian wrote:
I am kind of lost how this would work logically and am willing to
think
about it some more, but I do think we aren't going to simplify
postgresql.conf without such a facility.
Agreed. And I think it's a
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Really? I'm the opposite: I never leave a client's setting at 10, that's
just asking for trouble. Making it 100 *after* you encounter problem
queries is reactive; I prefer being proactive.
Have you ever measured the system speed before and
You guys call this simplification? You're out of your minds.
This proposal is ridiculously complicated, and yet it still fails
even to consider adjusting non-numeric parameters. And what about
things that require more than a trivial arithmetic expression to
compute? It's not hard at all to
Tom Lane wrote:
Josh Berkus [EMAIL PROTECTED] writes:
Oh, and wal_buffers, the default for which we should just change if it
weren't for SHMMAX.
Uh, why? On a workload of mostly small transactions, what value is
there in lots of wal_buffers?
None. But there's also little to no harm in
Greg Sabino Mullane wrote:
* The word 'paramters' is still misspelled. :)
Corrected for 8.4.
--
Bruce Momjian [EMAIL PROTECTED]http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
--
On Wed, 2008-06-11 at 11:45 -0400, Bruce Momjian wrote:
Greg Sabino Mullane wrote:
* The word 'paramters' is still misspelled. :)
Corrected for 8.4.
Technically this is a bug fix... why not backpatch it too?
--
Bruce Momjian [EMAIL PROTECTED]http://momjian.us
Heikki,
Ideally, of course, there would be no wal_buffers setting, and WAL
buffers would be allocated from shared_buffers pool on demand...
+1
--Josh
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Tom Lane wrote:
Josh Berkus [EMAIL PROTECTED] writes:
Oh, and wal_buffers, the default for which we should just change if it
weren't for SHMMAX.
Uh, why? On a workload of mostly small transactions, what value is
there in lots of wal_buffers?
Actually, it's also useful for any workload with
Josh Berkus wrote:
Heikki,
Ideally, of course, there would be no wal_buffers setting, and WAL
buffers would be allocated from shared_buffers pool on demand...
Same for pg_subtrans, pg_clog, etc (as previously discussed)
--
Alvaro Herrera
Robert Lor wrote:
Robert Treat wrote:
On Wednesday 04 June 2008 22:04:54 Greg Smith wrote:
I was just talking to someone today about building a monitoring tool for
this. Not having a clear way to recommend people monitor use of work_mem
and its brother spilled to disk sorts is an
Joshua D. Drake wrote:
On Wed, 2008-06-11 at 11:45 -0400, Bruce Momjian wrote:
Greg Sabino Mullane wrote:
* The word 'paramters' is still misspelled. :)
Corrected for 8.4.
Technically this is a bug fix... why not backpatch it too?
That might show up as a diff for people doing
Bruce Momjian wrote:
Joshua D. Drake wrote:
On Wed, 2008-06-11 at 11:45 -0400, Bruce Momjian wrote:
Greg Sabino Mullane wrote:
* The word 'paramters' is still misspelled. :)
Corrected for 8.4.
Technically this is a bug fix... why not backpatch it too?
That might show up as a diff for
Josh Berkus wrote:
Heikki,
Ideally, of course, there would be no wal_buffers setting, and WAL
buffers would be allocated from shared_buffers pool on demand...
+1
--Josh
+1
-Jignesh
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Dave Page wrote:
On Mon, Jun 2, 2008 at 5:46 AM, Joshua D. Drake [EMAIL PROTECTED] wrote:
I've seen people not doing so more often
than you would think. Perhaps because they are DBAs and not sysadmins? I
also
meant a tool to do things like verify that the changes are valid, as
someone
On Wed, Jun 11, 2008 at 6:56 PM, Bruce Momjian [EMAIL PROTECTED] wrote:
Dave Page wrote:
On Mon, Jun 2, 2008 at 5:46 AM, Joshua D. Drake [EMAIL PROTECTED] wrote:
pg_ctl -D data check?
I would +1 that.
I would also really like to see that - though I'd also like to see an
SQL interface
Dave Page wrote:
On Wed, Jun 11, 2008 at 6:56 PM, Bruce Momjian [EMAIL PROTECTED] wrote:
Dave Page wrote:
On Mon, Jun 2, 2008 at 5:46 AM, Joshua D. Drake [EMAIL PROTECTED] wrote:
pg_ctl -D data check?
I would +1 that.
I would also really like to see that - though I'd also like
Alvaro Herrera [EMAIL PROTECTED] writes:
Josh Berkus wrote:
Ideally, of course, there would be no wal_buffers setting, and WAL
buffers would be allocated from shared_buffers pool on demand...
Same for pg_subtrans, pg_clog, etc (as previously discussed)
I agree with that for pg_clog and
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
* Can we build a configuration wizard to tell newbies what settings
they need to tweak?
That would trump all the other suggestions conclusively. Anyone good at
expert systems?
How far could we get with the
Bruce Momjian [EMAIL PROTECTED] writes:
The second idea is the idea of having one parameter depend on another.
Not only could we do that for some of our existing parameters, but we
could have pseudo-parameters like concurrent_queries, memory_usage, and
extra_disk_space that could be at the
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
The second idea is the idea of having one parameter depend on another.
Not only could we do that for some of our existing parameters, but we
could have pseudo-parameters like concurrent_queries, memory_usage, and
extra_disk_space
Tom Lane [EMAIL PROTECTED] writes:
Alvaro Herrera [EMAIL PROTECTED] writes:
Josh Berkus wrote:
Ideally, of course, there would be no wal_buffers setting, and WAL
buffers would be allocated from shared_buffers pool on demand...
Same for pg_subtrans, pg_clog, etc (as previously discussed)
Greg,
At least that way we could always steal more if we want or return some, as
long as we're careful about when we do it. That would open the door to having
these parameters be dynamically adjustable. That alone would be worthwhile
even if we bypass all bells and whistles of the buffer
Magnus Hagander wrote:
Bruce Momjian wrote:
Joshua D. Drake wrote:
On Wed, 2008-06-11 at 11:45 -0400, Bruce Momjian wrote:
Greg Sabino Mullane wrote:
* The word 'paramters' is still misspelled. :)
Corrected for 8.4.
Technically this is a bug fix... why not backpatch it too?
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
The second idea is the idea of having one parameter depend on another.
We have tried to do that in the past, and it didn't work well *at all*.
We have? When?
Just a couple months ago we had to
Josh Berkus [EMAIL PROTECTED] writes:
Greg,
At least that way we could always steal more if we want or return some, as
long as we're careful about when we do it. That would open the door to having
these parameters be dynamically adjustable. That alone would be worthwhile
even if we bypass
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
I agree with that for pg_clog and friends, but I'm much more leery of
folding WAL into the same framework.
Well it may still be worthwhile stealing buffers from shared_buffers even if
we set a special flag marking
On Wed, 11 Jun 2008, Tom Lane wrote:
Who said anything about loops? What I am talking about is what happens
during
set memory_usage = X; // implicitly sets work_mem = X/100, say
set work_mem = Y;
set memory_usage = Z;
What is work_mem now, and what's your excuse for
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
The idea has a fundamental logical flaw, which is that it's not clear
which parameter wins if the user changes both.
Yes, you could get into problems by having variable dependency loops,
Who said anything about
Greg Smith wrote:
On Wed, 11 Jun 2008, Tom Lane wrote:
Who said anything about loops? What I am talking about is what happens
during
set memory_usage = X; // implicitly sets work_mem = X/100, say
set work_mem = Y;
set memory_usage = Z;
What is work_mem now, and what's
Josh Berkus [EMAIL PROTECTED] writes:
Greg,
Speak to the statisticians. Our sample size is calculated using the same
theory behind polls which sample 600 people to learn what 250 million
people are going to do on election day. You do NOT need (significantly)
larger samples for larger
Ron,
I wonder if the fastest way to generate the configurator
would be to simply ask everyone to post their tuned
postgresql.conf files along with a brief description of
the use case for that file. The we could group the
use-cases into various classes; and average the values
of the
Robert,
shared_buffers
effective_cache_size
default_stats_target
work_mem
maintainance_work_mem
listen_address
max_connections
the fsm parameters
checkpoint_segements
random_page_cost
My list is very similar, execept that I drop random_page_cost and add
synchronous_commit, autovaccum
On Tuesday 10 June 2008 09:37, Josh Berkus wrote:
Robert,
shared_buffers
effective_cache_size
default_stats_target
work_mem
maintainance_work_mem
listen_address
max_connections
the fsm parameters
checkpoint_segements
random_page_cost
My list is very similar, execept that I
Josh Berkus [EMAIL PROTECTED] writes:
Oh, and wal_buffers, the default for which we should just change if it
weren't for SHMMAX.
Uh, why? On a workload of mostly small transactions, what value is
there in lots of wal_buffers?
regards, tom lane
--
Sent via
Gregory Stark wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
...default_statistics_target?...Uhh 10.
Ah, but we only ever hear about the cases where it's wrong of course. In other
words even if we raised it to some optimal value we would still have precisely
the same experience of seeing
Tom,
Actually, the reason it's still 10 is that the effort expended to get it
changed has been *ZERO*. I keep asking for someone to make some
measurements, do some benchmarking, anything to make a plausible case
for a specific higher value as being a reasonable place to set it.
The silence has
Josh Berkus [EMAIL PROTECTED] writes:
Where analyze does systematically fall down is with databases over 500GB in
size, but that's not a function of d_s_t but rather of our tiny sample size.
Speak to the statisticians. Our sample size is calculated using the same
theory behind polls which
On 6/9/08, Gregory Stark [EMAIL PROTECTED] wrote:
Josh Berkus [EMAIL PROTECTED] writes:
Where analyze does systematically fall down is with databases over 500GB
in
size, but that's not a function of d_s_t but rather of our tiny sample
size.
n_distinct. For that Josh is right, we
Hakan Kocaman [EMAIL PROTECTED] writes:
On 6/9/08, Gregory Stark [EMAIL PROTECTED] wrote:
n_distinct. For that Josh is right, we *would* need a sample size
proportional to the whole data set which would practically require us to
scan the whole table (and have a technique for summarizing the
Greg,
Speak to the statisticians. Our sample size is calculated using the same
theory behind polls which sample 600 people to learn what 250 million
people are going to do on election day. You do NOT need (significantly)
larger samples for larger populations.
Your analogy is bad. For
Joshua D. Drake [EMAIL PROTECTED] writes:
On Fri, 2008-06-06 at 20:19 -0400, Tom Lane wrote:
Robert Treat [EMAIL PROTECTED] writes:
Actually, the reason it's still 10 is that the effort expended to get it
changed has been *ZERO*. I keep asking for someone to make some
measurements, do some
On Sunday 08 June 2008 19:07:21 Gregory Stark wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
On Fri, 2008-06-06 at 20:19 -0400, Tom Lane wrote:
Robert Treat [EMAIL PROTECTED] writes:
Actually, the reason it's still 10 is that the effort expended to get it
changed has been *ZERO*. I
David E. Wheeler wrote:
On Jun 5, 2008, at 14:47, Greg Smith wrote:
This is why there's the emphasis on preserving comments as they pass
into the GUC structure and back to an output file. This is one of the
implementation details I haven't fully made up my mind on: how to
clearly label
David E. Wheeler wrote:
How about a simple rule, such as that machine-generated comments start
with ##, while user comments start with just #? I think that I've
seen such a rule used before. At any rate, I think that, unless you
have some sort of line marker for machine-generated comments,
Andreas Pflug [EMAIL PROTECTED] writes:
Why do so many people here insist on editing postgresql.conf as primary means
of changing config params?
Isn't a psql -c SET foo=bar; MAKE PERSISTENT just as good as sed'ing
postgresql.conf or doing it manually?
no, it's awful.
Looking around for
Gregory Stark wrote:
Andreas Pflug [EMAIL PROTECTED] writes:
Why do so many people here insist on editing postgresql.conf as primary means
of changing config params?
Isn't a psql -c SET foo=bar; MAKE PERSISTENT just as good as sed'ing
postgresql.conf or doing it manually?
no, it's
Andreas Pflug [EMAIL PROTECTED] writes:
Gregory Stark wrote:
Andreas Pflug [EMAIL PROTECTED] writes:
Why do so many people here insist on editing postgresql.conf as primary
means
of changing config params?
Isn't a psql -c SET foo=bar; MAKE PERSISTENT just as good as sed'ing
Gregory Stark wrote:
So all you have is our existing file except with an additional layer of
quoting to deal with, a useless SET keyword to annoy users, and a file that
you need a bison parser
Don't you think that's a little over the top, throwing bison at the
simple task to extend
Am Mittwoch, 4. Juni 2008 schrieb Aidan Van Dyk:
When reading this thread, I'm wondering if anybody ever saw a config
file for a complex software product that was easily editable and
understandable. I don't know one. If there was one, it'd be nice to know
it so we can learn from it.
Am Mittwoch, 4. Juni 2008 schrieb Tom Lane:
* Can we present the config options in a more helpful way (this is 99%
a documentation problem, not a code problem)?
ack
* Can we build a configuration wizard to tell newbies what settings
they need to tweak?
Some questions to clarify this:
-
Am Donnerstag, 5. Juni 2008 schrieb Tom Lane:
How far could we get with the answers to just three questions:
* How many concurrent queries do you expect to have?
* How much RAM space are you willing to let Postgres use?
* How much overhead disk space are you willing to let Postgres use?
* Andreas Pflug [EMAIL PROTECTED] [080606 04:50]:
David E. Wheeler wrote:
How about a simple rule, such as that machine-generated comments start
with ##, while user comments start with just #? I think that I've
seen such a rule used before. At any rate, I think that, unless you
have some
* Peter Eisentraut [EMAIL PROTECTED] [080606 08:25]:
Am Mittwoch, 4. Juni 2008 schrieb Aidan Van Dyk:
When reading this thread, I'm wondering if anybody ever saw a config
file for a complex software product that was easily editable and
understandable. I don't know one. If there was one,
Andreas Pflug [EMAIL PROTECTED] writes:
Gregory Stark wrote:
So all you have is our existing file except with an additional layer of
quoting to deal with, a useless SET keyword to annoy users, and a file that
you need a bison parser
Don't you think that's a little over the top, throwing
Peter Eisentraut [EMAIL PROTECTED] writes:
And note that one of the major advances in X.org over XFree86 was that all
the
useless garbage was removed from the configuration file, so that the final
and usable configuration fits on one screen, and you can even write it from
memory if you
Andreas Pflug [EMAIL PROTECTED] writes:
Text config files are NOT friendly for beginner and mediocre users. IMHO
the current restriction on GUC changes is a major obstacle towards pgsql
tuning tools, e.g. written as a Google SoC project. Graphic tools aren't
too popular at pgsql-hackers,
Peter Eisentraut [EMAIL PROTECTED] writes:
- If we know better values, why don't we set them by default?
The problem is: better for what? In particular, I'm uncomfortable with
any changes in the direction of trying to make Postgres take over the
entire machine by default. I'd want some fairly
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
- If we know better values, why don't we set them by default?
The problem is: better for what? In particular, I'm uncomfortable with
any changes in the direction of trying to make Postgres take over the
entire machine by default.
Am Freitag, 6. Juni 2008 schrieb Tom Lane:
Peter Eisentraut [EMAIL PROTECTED] writes:
- If we know better values, why don't we set them by default?
The problem is: better for what? In particular, I'm uncomfortable with
any changes in the direction of trying to make Postgres take over the
Peter Eisentraut wrote:
Am Freitag, 6. Juni 2008 schrieb Tom Lane:
Peter Eisentraut [EMAIL PROTECTED] writes:
- If we know better values, why don't we set them by default?
The problem is: better for what? In particular, I'm uncomfortable with
any changes in the direction of trying to make
Am Freitag, 6. Juni 2008 schrieb Joshua D. Drake:
That is where some 80% solution sample config files come in.
Considering that writing a sample configuration file is trivial, yet I haven't
seen a single one posted in the six or more years of GUC, I have no faith in
this plan until I actually
Peter Eisentraut wrote:
Am Freitag, 6. Juni 2008 schrieb Joshua D. Drake:
That is where some 80% solution sample config files come in.
Considering that writing a sample configuration file is trivial, yet I haven't
seen a single one posted in the six or more years of GUC, I have no faith in
On Jun 5, 2008, at 23:08, Heikki Linnakangas wrote:
What comments do we consider machine-generated? Just the ones used
to comment out settings, like
#shared_buffers = 32MB
or something else?
Those and documentation comments.
If the automatic tool lets alone all other kind of comments, I
1 - 100 of 225 matches
Mail list logo
