Hi,
As I promised before we would like to propose implementing the
recursive query as defined in the standard for PostgreSQL 8.4.
The work is supported by Sumitomo Electric Information Systems Co.,
Ltd. (http://www.sei-info.co.jp/) and SRA OSS, Inc. Japan
(http://www.sraoss.co.jp).
1. Overview
ITAGAKI Takahiro [EMAIL PROTECTED] writes:
4. ANALYZE finishes in a short time.
It is ok that VACUUM takes a long time because it is not a transaction,
but ANALYZE should not. It requres cleverer statistics algorithm.
Sampling factor 10 is not enough for pg_stats.n_distinct. We seems
Am Dienstag, 19. Februar 2008 schrieb Tom Lane:
Previously, AC_FUNC_FSEEKO did this to test if fseeko was available:
return !fseeko;
Now it does this:
return fseeko (stdin, 0, 0) (fseeko) (stdin, 0, 0);
Unfortunately, that gives the compiler enough of a syntactic clue
to
On Feb 19, 2008 1:22 PM, Magnus Hagander [EMAIL PROTECTED] wrote:
I'd like to add a way for a client (in this case, typicallyi pgadmin,
phppgadmin or similar) to get the available options on the server for the
GUC settings we have that take fixed options. This is to make it possible
to
Magnus Hagander wrote:
That would work for all the settings here I think, except for log_destinatino
which actually supports multiple choices from the enumeration. But that
would be fairly easy to implement on top of it.
I think DateStyle should also be considered carefully, given how it has
I like option 1 the best. Minimally invasive, and probably
easier to handle on the client than 2.
+1
---(end of broadcast)---
TIP 6: explain analyze is your friend
Currently, pgAdmin supports editing postgresql.conf remotely using the
adminpack to open the file, change it locally in memory, and using the
adminpack again to write it back. This means that in theory pgAdmin needs a
full postgresql.conf parser. Right now it doesn't have this - it just
exposes
I'd like to add a way for a client (in this case, typicallyi pgadmin,
phppgadmin or similar) to get the available options on the server for the
GUC settings we have that take fixed options. This is to make it possible
to generate pretty dropdown lists of the options.
One way would be to simply
On Tue, Feb 19, 2008 at 02:56:42PM +0100, Peter Eisentraut wrote:
Am Dienstag, 19. Februar 2008 schrieb Magnus Hagander:
1) Extend pg_settings with a column that contains an array of the available
options. Extend the config_string GUC struct with a hook that can return
this data.
Before
On Tue, Feb 19, 2008 at 11:17:51AM -0300, Alvaro Herrera wrote:
Magnus Hagander wrote:
That would work for all the settings here I think, except for
log_destinatino
which actually supports multiple choices from the enumeration. But that
would be fairly easy to implement on top of it.
-Original Message-
From: [EMAIL PROTECTED] [mailto:pgsql-hackers-
[EMAIL PROTECTED] On Behalf Of Magnus Hagander
Sent: Tuesday, February 19, 2008 8:36 AM
To: pgsql-hackers
Subject: [HACKERS] Permanent settings
What I'd really like to see is something like a new keyword on the SET
* Magnus Hagander [EMAIL PROTECTED] [080219 09:37]:
One way might be to simply have the config file reader store the location
for each setting where it was found, and when you do a SET PERMANENT (if
that's what we'd call it) it'll go back to that place and make the
modification there. If a
Am Dienstag, 19. Februar 2008 schrieb Magnus Hagander:
1) Extend pg_settings with a column that contains an array of the available
options. Extend the config_string GUC struct with a hook that can return
this data.
Before we get to the interface for reporting this to the client, I wonder how
Hi,
One thing that occurred to me when reading the Ad Hoc Indexes
thread was that PG doesn't seem to do much with tidying up common
sub-expressions (I'm not sure why I remembered about it as it's not
particularly related, strange). Anyway, as an example imagine I have a
large table that I want
On Tue, Feb 19, 2008 at 04:38:16PM +0100, Csaba Nagy wrote:
Are you suggesting we keep appending? So if I set the same parameter 100
times, it would show up on 100 rows?
What about not touching the config file at all, but write to a separate
file which is completely under the control of
Are you suggesting we keep appending? So if I set the same parameter 100
times, it would show up on 100 rows?
What about not touching the config file at all, but write to a separate
file which is completely under the control of postgres and include that
at the end of the config file ? You just
Aidan Van Dyk wrote:
Any set permanent settings should be *appended* to the main config
file, preferably with a comment line, like:
# Set by user USER from client CLIENT on TIMESTAMP
some_guc option = some_value
Are you suggesting we keep appending? So if I set the same
Peter Eisentraut [EMAIL PROTECTED] writes:
Please try the attached patch.
Shortly.
What is currently the consequence of the problem? Does it fail to build,
fail
to run, or does it fail with large files?
The consequence of the problem is that pg_dump/pg_restore are compiled
without any
On Tue, Feb 19, 2008 at 11:09:43AM -0500, Aidan Van Dyk wrote:
* Magnus Hagander [EMAIL PROTECTED] [080219 10:39]:
On Tue, Feb 19, 2008 at 10:34:26AM -0500, Aidan Van Dyk wrote:
Are you suggesting we keep appending? So if I set the same parameter 100
times, it would show up on 100 rows?
Folks,
Let's put PL/PgSQL in template1 by default, as some downstream
packagers are already doing. If someone really must remove it, they
can still do that.
Cheers,
David.
--
David Fetter [EMAIL PROTECTED] http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype:
Magnus Hagander wrote:
On Tue, Feb 19, 2008 at 03:53:11PM +, Richard Huxton wrote:
Magnus Hagander wrote:
What I'd really like to see is something like a new keyword on the SET
command, so you could to SET PERMANENT foo=bar, which would write the
configuration back into postgresql.conf.
I
On Tue, Feb 19, 2008 at 09:53:30AM -0500, Aidan Van Dyk wrote:
* Magnus Hagander [EMAIL PROTECTED] [080219 09:37]:
One way might be to simply have the config file reader store the location
for each setting where it was found, and when you do a SET PERMANENT (if
that's what we'd call it)
On Tue, Feb 19, 2008 at 11:11:05AM -0500, Aidan Van Dyk wrote:
* Csaba Nagy [EMAIL PROTECTED] [080219 10:59]:
Are you suggesting we keep appending? So if I set the same parameter 100
times, it would show up on 100 rows?
What about not touching the config file at all, but write to a
On Tue, Feb 19, 2008 at 11:14:59AM -0500, Andrew Dunstan wrote:
Richard Huxton wrote:
Magnus Hagander wrote:
Right. I don't think we have any settings that depend on order, do we?
That's what I was trying to think of - nothing came to mind.
custom_variable_classes and dependents?
Gregory Stark wrote:
The alternative is to have two files and read them both. Then if you change a
variable which is overridden by the other source you can warn that the change
is ineffective.
I think on balance the include file method is so much simpler that I prefer
it.
I think this is
Magnus Hagander wrote:
What I'd really like to see is something like a new keyword on the SET
command, so you could to SET PERMANENT foo=bar, which would write the
configuration back into postgresql.conf.
I don't have a complete solution for how to actually implement it, so I'm
just throwing
On Tue, Feb 19, 2008 at 10:34:26AM -0500, Aidan Van Dyk wrote:
* Magnus Hagander [EMAIL PROTECTED] [080219 10:28]:
But if you *need* a way to set permanent, couldn't you do with with
the following KISS idea?
Any set permanent settings should be *appended* to the main config
On Tue, Feb 19, 2008 at 12:11:05PM -0500, Tom Lane wrote:
David Fetter [EMAIL PROTECTED] writes:
Let's put PL/PgSQL in template1 by default, as some downstream
packagers are already doing. If someone really must remove it,
they can still do that.
This has been proposed before, and
Richard Huxton wrote:
Magnus Hagander wrote:
Right. I don't think we have any settings that depend on order, do we?
That's what I was trying to think of - nothing came to mind.
custom_variable_classes and dependents?
cheers
andrew
---(end of
Gregory Stark wrote:
The alternative is to have two files and read them both. Then if you
change a
variable which is overridden by the other source you can warn that
the
change
is ineffective.
I think on balance the include file method is so much simpler that I
prefer it.
I
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Dienstag, 19. Februar 2008 schrieb Tom Lane:
Unfortunately, that gives the compiler enough of a syntactic clue
to guess that fseeko is probably an undeclared function, and therefore
*it will not error out*, only generate a warning, if it's not seen
David Fetter [EMAIL PROTECTED] writes:
Let's put PL/PgSQL in template1 by default, as some downstream
packagers are already doing. If someone really must remove it, they
can still do that.
This has been proposed before, and rejected before. Have you got any
new arguments?
* Csaba Nagy [EMAIL PROTECTED] [080219 10:59]:
Are you suggesting we keep appending? So if I set the same parameter 100
times, it would show up on 100 rows?
What about not touching the config file at all, but write to a separate
file which is completely under the control of postgres and
On Tue, Feb 19, 2008 at 03:53:11PM +, Richard Huxton wrote:
Magnus Hagander wrote:
What I'd really like to see is something like a new keyword on the SET
command, so you could to SET PERMANENT foo=bar, which would write the
configuration back into postgresql.conf.
I don't have a
On Tue, 2008-02-19 at 16:41 +0100, Magnus Hagander wrote:
The end result wouldn't be as clean as some would expect, but it would
certainly be easier code-wise. For example, I'm sure someone would get the
suggestion to go edit postgresql.conf to change a config value, and be
surprised when it
* Magnus Hagander [EMAIL PROTECTED] [080219 10:39]:
On Tue, Feb 19, 2008 at 10:34:26AM -0500, Aidan Van Dyk wrote:
Are you suggesting we keep appending? So if I set the same parameter 100
times, it would show up on 100 rows?
In my opinion, absolutely. It's easy, safe, and the overhead
* Magnus Hagander [EMAIL PROTECTED] [080219 10:28]:
But if you *need* a way to set permanent, couldn't you do with with
the following KISS idea?
Any set permanent settings should be *appended* to the main config
file, preferably with a comment line, like:
# Set by user USER from
Magnus Hagander [EMAIL PROTECTED] writes:
Yeah, that may actually be a very good way to implement it. I don't like
the idea of continously appending to an existing file, but if we did have a
separate file with a tightly controlled format that would be doable.
+1
Separating the automatically
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
What I'd really like to see is something like a new keyword on the SET
command, so you could to SET PERMANENT foo=bar, which would write the
configuration back into postgresql.conf.
FWIW, I made a Pl/PerlU function that did this at one
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 19 Feb 2008 15:36:26 +0100
Magnus Hagander [EMAIL PROTECTED] wrote:
Currently, pgAdmin supports editing postgresql.conf remotely using the
adminpack to open the file, change it locally in memory, and using the
adminpack again to write it
David Fetter [EMAIL PROTECTED] writes:
On Tue, Feb 19, 2008 at 12:11:05PM -0500, Tom Lane wrote:
This has been proposed before, and rejected before. Have you got
any new arguments?
The longer it's been since the last vuln in PL/PgSQL, the harder it is
to argue for having it not be there by
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 18 Feb 2008 15:59:29 -0500 (EST)
Greg Smith [EMAIL PROTECTED] wrote:
On Sun, 17 Feb 2008, Christian Robottom Reis wrote:
Ah, interesting. Do you have a URL for the Subversion conversion?
Is it a mirror of CVS, and if so, how often is
Alvaro Herrera wrote:
Joshua D. Drake wrote:
IMO this should all be in the database and that's it. The idea that our
global settings are in a file seems unusual consider we have a
perfectly good storage engine available.
That doesn't work, because many settings must be loaded
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 19 Feb 2008 15:22:42 -0300
Alvaro Herrera [EMAIL PROTECTED] wrote:
Joshua D. Drake wrote:
IMO this should all be in the database and that's it. The idea that
our global settings are in a file seems unusual consider we have a
Joshua D. Drake wrote:
IMO this should all be in the database and that's it. The idea that our
global settings are in a file seems unusual consider we have a
perfectly good storage engine available.
That doesn't work, because many settings must be loaded before the
database is fully
Joshua D. Drake [EMAIL PROTECTED] writes:
IMO this should all be in the database and that's it. The idea that our
global settings are in a file seems unusual consider we have a
perfectly good storage engine available.
The sufficient reason why not is that many of these settings must be
On Tue, Feb 19, 2008 at 02:19:16PM -0300, Alvaro Herrera wrote:
Gregory Stark wrote:
The alternative is to have two files and read them both. Then if you change
a
variable which is overridden by the other source you can warn that the
change
is ineffective.
I think on balance
On Tue, Feb 19, 2008 at 04:58:21PM +, Gregory Stark wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
Yeah, that may actually be a very good way to implement it. I don't like
the idea of continously appending to an existing file, but if we did have a
separate file with a tightly
Andrew Dunstan wrote:
Alvaro Herrera wrote:
Joshua D. Drake wrote:
IMO this should all be in the database and that's it. The idea that our
global settings are in a file seems unusual consider we have a
perfectly good storage engine available.
That doesn't work, because many
Magnus Hagander [EMAIL PROTECTED] writes:
On Tue, Feb 19, 2008 at 04:58:21PM +, Gregory Stark wrote:
The include file method is workable but isn't perfect. What happens if a user
connects with pgadmin and changes a parameter but that parameter is
overridden
by a variable in the config
On Tue, 2008-02-19 at 19:38 +, Gregory Stark wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
On Tue, Feb 19, 2008 at 04:58:21PM +, Gregory Stark wrote:
The include file method is workable but isn't perfect. What happens if a
user
connects with pgadmin and changes a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 7 Feb 2008 18:40:37 -0800
Joshua D. Drake [EMAIL PROTECTED] wrote:
On Thu, 7 Feb 2008 18:32:41 -0800
Joshua D. Drake [EMAIL PROTECTED] wrote:
Do you want counts or actual output?
% time seconds usecs/call callserrors
I have started to develop this item. I would like to see whether I am on the
right track.
1. For this item we need an array of localized month/day names. I was
thinking of (re)initializing the array item using palloc, repalloc pfree
etc.. when SET LC_MESSAGES is called. Would this be correct?
2.
On Tue, 2008-02-19 at 13:31 -0800, Josh Berkus wrote:
Magnus, All,
This is something I've been thinking about too, just because my efforts to
write auto-config scripts have gotten bogged down in the need to parse and
write .conf files in a paltform-agnostic way and preserve comments. I
On Wed, 2008-02-06 at 15:13 +, Simon Riggs wrote:
The -s option creates the table, as well as creating constraints and
indexes. These objects need to be dropped prior to loading, if we are to
follow the performance recommendations in the docs. But the only way to
do that is to manually
Magnus, All,
This is something I've been thinking about too, just because my efforts to
write auto-config scripts have gotten bogged down in the need to parse and
write .conf files in a paltform-agnostic way and preserve comments. I
agree with Magnus that it's something we need to address.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 19 Feb 2008 13:21:46 -0800
Joshua D. Drake [EMAIL PROTECTED] wrote:
Were their any thoughts on this? I am also finding that backing up
this database is rudely slow with the same type of odd metrics
(almost zero (or zero) iowait). We can
Magnus,
That's basically include but with a different name, no?
Yes. FWIW, I seem to be lagged about 3 hours on -hackers.
Why do you need to split it in two columns, and what would go in what
column?
Current data:
postgres=# select name, category from pg_settings;
name
Tom Lane wrote:
David Fetter [EMAIL PROTECTED] writes:
On Tue, Feb 19, 2008 at 12:11:05PM -0500, Tom Lane wrote:
This has been proposed before, and rejected before. Have you got
any new arguments?
The longer it's been since the last vuln in PL/PgSQL, the harder it is
to
One idea would be to remove duplicate postgresql.conf appended entries
on server start.
---
Josh Berkus wrote:
Magnus,
That's basically include but with a different name, no?
Yes. FWIW, I seem to be lagged about 3
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 19 Feb 2008 18:13:53 -0500
Andrew Dunstan [EMAIL PROTECTED] wrote:
I am having trouble locating the previous thread - can someone please
point me at it?
I am having trouble finding one that makes a cohesive argument against
but here we
On Tuesday 19 February 2008 15:05, Bruce Momjian wrote:
One idea would be to remove duplicate postgresql.conf appended entries
on server start.
I think anything which has us appending extra settings to the end of the
file is a non-starter. We'd get I changed the setting, but nothing's
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 19 Feb 2008 15:25:44 -0800
Neil Conway [EMAIL PROTECTED] wrote:
On Tue, 2008-02-19 at 18:13 -0500, Andrew Dunstan wrote:
I am having trouble locating the previous thread - can someone
please point me at it?
On Tue, 2008-02-19 at 18:13 -0500, Andrew Dunstan wrote:
I am having trouble locating the previous thread - can someone please
point me at it?
http://markmail.org/message/kyjbj5qovadfoe3w
-Neil
---(end of broadcast)---
TIP 7: You can help
Neil Conway wrote:
On Tue, 2008-02-19 at 18:13 -0500, Andrew Dunstan wrote:
I am having trouble locating the previous thread - can someone please
point me at it?
http://markmail.org/message/kyjbj5qovadfoe3w
Thanks. The only significant problem I saw mentioned other than the
Andrew Dunstan [EMAIL PROTECTED] writes:
Thanks. The only significant problem I saw mentioned other than the
rather ephemeral security issues was the one regarding statically linked
postgres.
Nothing like establishing one's point by carefully ignoring all the
nontrivial problems.
I think
Josh Berkus [EMAIL PROTECTED] writes:
On Tuesday 19 February 2008 15:05, Bruce Momjian wrote:
One idea would be to remove duplicate postgresql.conf appended entries
on server start.
I think anything which has us appending extra settings to the end of the
file is a non-starter. We'd get I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
ignore this
-
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED]
Yahoo . yscrappy Skype: hub.orgICQ . 7615664
Tom Lane wrote:
Still and all, I will hold still for having it be installed by default
as long as there is a simple way for the DBA to change that default
--- let's say, roughly as simple as it is now for the DBA to make it the
default if he wishes (ie create language plpgsql in template1)
ignore, just a test
--
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED]
Yahoo . yscrappy Skype: hub.orgICQ . 7615664
---(end of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 19 Feb 2008 13:36:48 -0800
Joshua D. Drake [EMAIL PROTECTED] wrote:
Hello,
Some more testing on this. This time (using 8.3) I modified my restore
process to use multiple processes by manipulating TOC files. I used
three processes for the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
ignore this one too
-
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED]
Yahoo . yscrappy Skype: hub.orgICQ . 7615664
As discussed a little while back, I would like to add a generic trigger
function which will force an update to skip if the new and old tuples
are identical.
The guts of this is the following snippet of code:
|rettuple = newtuple = trigdata-tg_newtuple;
oldtuple =
Bah.
It's the stuff in the format translation path and conversion to/from datums
that is the bottleneck.
We sped up COPY TO recently by a factor of 10 using similar approaches to
what we did for COPY FROM in the past. There's a format conversion that is
the culprit.
We routinely get about 12
On Tuesday 19 February 2008 20:08, Tom Lane wrote:
Josh Berkus [EMAIL PROTECTED] writes:
On Tuesday 19 February 2008 15:05, Bruce Momjian wrote:
One idea would be to remove duplicate postgresql.conf appended entries
on server start.
I think anything which has us appending extra settings
Gregory Stark [EMAIL PROTECTED] wrote:
4. ANALYZE finishes in a short time.
There was a paper with a nice algorithm posted a while back which required
only constant memory but it depended on scanning the entire table. I think to
do n_distinct estimates we'll need some statistics which are
On Tuesday 19 February 2008 14:32, Andrew Dunstan wrote:
Andrew Dunstan wrote:
Alvaro Herrera wrote:
Joshua D. Drake wrote:
IMO this should all be in the database and that's it. The idea that our
global settings are in a file seems unusual consider we have a
perfectly good storage
Hi list,
I see the following business opportunity for Postgres:
I) Simple man can't program middleware to connect XML-client and
Postgres.
II) Request into several databases does not exist.
III) Notebooks need several switching-on and switching-off during
transaction.
IV) Distance between strings
78 matches
Mail list logo
