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
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
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 g
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
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 MB
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 = trigdata->t
-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
-
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 broadcast)
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) a
-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
-
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED]
Yahoo . yscrappy Skype: hub.orgICQ . 7615664
-BEGI
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
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 thin
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
ra
-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?
>
> http://markmail.org
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
happ
-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 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 su
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
t
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 a
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
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
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.
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. Ha
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.
-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
-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
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
"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 i
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 settin
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 tig
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 thin
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 before
-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" <[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
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 operati
-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
-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 oft
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 t
>
> 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
> pre
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,
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
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 th
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?
"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 automati
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: davi
-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 po
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_classe
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
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 broadcast)-
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 wr
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 from client on
some_guc option = some_value
Are you suggesting we keep appending? So if I set the same parameter 100
tim
* 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 postgre
* 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
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 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
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
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 out
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
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
> 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
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 a
* 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 b
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
Naz Gassiep wrote:
> It may also be beneficial to add the ISO 3166 column into that view, the
> data is in zone.tab and I can't see a reason to not include it.
We also have the country name in iso3166.tab and the geo coordinates.
And there is also a comment field. Which ones make sense to add?
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
> -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 t
* 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. I
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 the
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
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 ha
> 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
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.
>
>
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
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 ge
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 pre
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
"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. W
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
79 matches
Mail list logo
