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 bette
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
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.
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 prod
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 absolut
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 represent
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 sp
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, etc.
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 abou
-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
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 have
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 h
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 o
"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 peo
"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 becau
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 fut
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 set
Radek Strnad napsal(a):
Zdenek Kotala wrote:
Radek Strnad napsal(a):
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,
UCS_BASIC)
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('USE
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
[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:
http://www.joeconway.com/sessfunc.
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 fam
-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 Mu
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 re
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
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)
f
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 ht
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 A
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)
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
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 it
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
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
33 matches
Mail list logo