Le vendredi 30 mai 2008, Dimitri Fontaine a écrit :
This way, no need to switch IP addresses, the clients just connect as usual
and get results back and do not have to know whether the host they're
qerying against is a slave or a master. This level of smartness is into
-core.
Oh, and if you
On Fri, May 30, 2008 at 6:47 PM, Andreas 'ads' Scherbaum
[EMAIL PROTECTED] wrote:
On Fri, 30 May 2008 17:05:57 -0400 Andrew Dunstan wrote:
Andreas 'ads' Scherbaum wrote:
On Thu, 29 May 2008 23:02:56 -0400 Andrew Dunstan wrote:
Well, yes, but you do know about archive_timeout, right? No
On Fri, 2008-05-30 at 17:34 -0700, Josh Berkus wrote:
There's obviously some refinements needed, but what do people think of
the above general idea?
My initial reaction is that this is too much change, though I agree with
many of the points and understand it is well intended.
We have many
Jan Urba??ski wrote:
Preference SQL is an extension to regular SQL, that allows expressing
preferences in SQL queries. Preferences are like soft WHERE clauses. A
preference doesn't need to be satisfied by a tuple for it to appear in
the result set, but it's preferred it is. More strictly, a set
Stephen R. van den Berg wrote:
Jan Urbański wrote:
An example of a preference query would be (quoting the linked PDF):
SELECT * FROM programmers PREFERRING exp IN ('java', 'C++');
or
SELECT * FROM computers
PREFERRING HIGHEST(main_memory) AND HIGHEST(cpu_speed);
Forgive my ignorance, but
I have implemented a solution for global variables implemented in plpython and
I need implement this in c :)
My implementation:
select set_session('USER','coutinho');
select set_session('EMAIL','[EMAIL PROTECTED]');
select get_session('USER');
coutinho
select get_session('EMAIL');
[EMAIL
Yes, the preference clause can be rewritten using standard SQL. The syntax to
duplicate the example result set is listed below. The syntax is not very
flexible or easy to read.
select id
from computer
where (main_memory = (select max(main_memory)
from computer)
On Sat, May 31, 2008 at 2:18 AM, Mike Rylander [EMAIL PROTECTED] wrote:
On Fri, May 30, 2008 at 6:47 PM, Andreas 'ads' Scherbaum
[EMAIL PROTECTED] wrote:
On Fri, 30 May 2008 17:05:57 -0400 Andrew Dunstan wrote:
Andreas 'ads' Scherbaum wrote:
On Thu, 29 May 2008 23:02:56 -0400 Andrew Dunstan
Jan Urbański wrote:
SELECT * FROM computers
PREFERRING HIGHEST(main_memory) AND HIGHEST(cpu_speed);
This seems similar to the SKYLINE OF patch that was discussed a year (?)
ago. Are you familiar with that project? Can you summarize the differences?
--
Heikki Linnakangas
EnterpriseDB
Kevin Walker wrote:
Yes, the preference clause can be rewritten using standard SQL. The syntax to duplicate the example result set is listed below. The syntax is not very flexible or easy to read.
select id
from computer
where (main_memory = (select max(main_memory)
Merlin Moncure wrote:
On Sat, May 31, 2008 at 2:18 AM, Mike Rylander [EMAIL PROTECTED] wrote:
On Fri, May 30, 2008 at 6:47 PM, Andreas 'ads' Scherbaum
Compression especially is going to negate one of the big advantages of
wal shipping, namely that it is cheap investment in terms of load to
Simon Riggs wrote:
On Fri, 2008-05-30 at 17:34 -0700, Josh Berkus wrote:
We have many supporters, though 90% of them seldom touch the database
from one release to the next. Many are dismayed that every time they do
we've fiddled with the knobs so some don't work anymore, some are
missing or
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Many are dismayed that every time they do we've fiddled with the
knobs so some don't work anymore, some are missing or renamed and
there's a few new ones.
...
* We should rename effective_cache_size
*raises eyebrow*
- --
Greg Sabino
Heikki Linnakangas wrote:
Jan Urbański wrote:
SELECT * FROM computers
PREFERRING HIGHEST(main_memory) AND HIGHEST(cpu_speed);
This seems similar to the SKYLINE OF patch that was discussed a year (?)
ago. Are you familiar with that project? Can you summarize the differences?
Oh, I wasn't
[EMAIL PROTECTED] wrote:
I have implemented a solution for global variables implemented in plpython and
I need implement this in c :)
The below listed tarball is out of date at this point, but I have
updated code laying around if someone really wanted it:
Josh Berkus [EMAIL PROTECTED] writes:
Currently, PostgreSQL,conf and our set of GUC configurations suffer from
4 large problems:
1. Most people have no idea how to set these.
2. The current postgresql.conf file is a huge mess of 194 options, the
vast majority of which most users will never
Hello
2008/5/31 [EMAIL PROTECTED]:
I have implemented a solution for global variables implemented in plpython
and I need implement this in c :)
My implementation:
select set_session('USER','coutinho');
select set_session('EMAIL','[EMAIL PROTECTED]');
select get_session('USER');
Radek Strnad napsal(a):
Zdenek Kotala wrote:
Radek Strnad napsal(a):
snip
I'm thinking of dividing the problem into two parts - in beginning
pg_collation will contain two functions. One will have hard-coded rules
for these basic collations (SQL_CHARACTER, GRAPHIC_IRV, LATIN1, ISO8BIT,
On May 31, 2008, at 09:23, Tom Lane wrote:
1. Most people have no idea how to set these.
2. The current postgresql.conf file is a huge mess of 194 options,
the
vast majority of which most users will never touch.
3. GUCS lists are kept in 3 different places (guc.c, postgresql.conf,
and the
Simon, Tom, Greg,
Now, that will get a lot easier just by
virtue of having a smaller config file, but I think that adding something
into pg_settings that allows saving user-added commentary would be a nice
step toward some useful standardization on that side of things. It would
make future
David E. Wheeler [EMAIL PROTECTED] writes:
I'd love to see these issues resolved. The current postgresql.conf is way
over
the top. Might you have a better idea?
I don't think fiddling with surface issues like the formatting of the
postgresql.conf is productive. Hiding parameters because you
Josh Berkus [EMAIL PROTECTED] writes:
It's my viewpoint based on a lot of user feedback that the current
postgresql.conf is fundamentally broken and a major roadblock to PostgreSQL
adoption. This was a point with which there was pretty much universal
agreement when I talked with people at
On May 31, 2008, at 12:36, Gregory Stark wrote:
What this sounds like is a sly way to try to get rid of
postgresql.conf
entirely and replace it with parameters stored in the database so
admins would
adjust the parameters using an SQL syntax rather than a text file.
There are pros and cons
Josh Berkus wrote:
Currently, PostgreSQL,conf and our set of GUC configurations suffer from
4 large problems:
As we have talked about it before, you know that I agree that the GUC system
could use some improvements. But I'm a bit surprised about some of your
assessments.
1. Most people
On May 31, 2008, at 15:32, Peter Eisentraut wrote:
1. Most people have no idea how to set these.
Could you clarify this? I can't really believe that people are
incapable of
editing a configuration file.
I've been using PostgreSQL on and off, mostly on, for almost 10 years.
I still
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
In the interest of constructive criticism, here's some
ways I think postgresql.conf could be improved.
* A weak +1 to the #include idea. I'm much more inclined to simply
add a new section to the bottom of the file and use version
control, but
I have attached a new patch with respect to the current cvs head. This
produces headline in a document for a given query. Basically it
identifies fragments of text that contain the query and displays them.
DESCRIPTION
HeadlineParsedText contains an array of actual words but not
information
Previous thread for reference:
http://archives.postgresql.org/pgsql-patches/2007-06/msg00096.php
The objections to synchronized scans for VACUUM as listed in that thread
(summary):
1. vacuum sometimes progresses faster than a regular heapscan, because
it doesn't need to check WHERE clauses,
Jeff Davis [EMAIL PROTECTED] writes:
The objections to synchronized scans for VACUUM as listed in that thread
(summary):
2. vacuum takes breaks from the scan to clean up the indexes when it
runs out of maintenance_work_mem.
2. There have been suggestions about a more compact representation
Greg Sabino Mullane wrote:
* A weak +1 to the #include idea. I'm much more inclined to simply
add a new section to the bottom of the file and use version
control, but I could see ways in which include would be useful.
We already have include directives, and have had since 8.2.
Thus
Greg Sabino Mullane wrote:
* Much more verbose comments. The abovementioned default_statistics_target
is a very important settings, but there is zero explanation in the file
of what it is. The only thing we're told is that it ranges from 10 - 1000.
We can do better than that. Users would
Hi,
I don't know where I can find the doxyfile which generate
doxygen.postgresql.org web site. I found that when reading code the
doxygen source code is quite helpful. However, I want to generate an
off-line copy of doxygen docs myself, but I can't find the doxyfile in
the lastest source release.
Jan,
;-) ... agree with your points. Note I wasn't trying to duplicate the full
functionality of the preferences clause. ...just pointing out that the example
presented could be duplicated with standard SQL with the result being both ugly
and confusing.
My intent was show that the syntax
I have attached a patch for phrase search with respect to the cvs head.
Basically it takes a a phrase (text) and a TSVector. It checks if the
relative positions of lexeme in the phrase are same as in their
positions in TSVector.
If the configuration for text search is simple, then this will
Can I express one's user view:
Greg Sabino Mullane writes:
* Much more verbose comments. The abovementioned default_statistics_target
is a very important settings, but there is zero explanation in the file
of what it is. The only thing we're told is that it ranges from 10 - 1000.
We can do
35 matches
Mail list logo
