Joshua D. Drake wrote:
> On Sat, 2007-01-06 at 23:38 -0500, Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > The attached patch warns users when they create documentation output
> > > that has no index, and suggests re-running 'gmake'.
> >
> > This is just useless noise. If it
On Sat, 2007-01-06 at 23:38 -0500, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > The attached patch warns users when they create documentation output
> > that has no index, and suggests re-running 'gmake'.
>
> This is just useless noise. If it could tell the difference between a
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > The attached patch warns users when they create documentation output
> > > that has no index, and suggests re-running 'gmake'.
> >
> > This is just useless noise. If it could tell the difference between an
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > The attached patch warns users when they create documentation output
> > that has no index, and suggests re-running 'gmake'.
>
> This is just useless noise. If it could tell the difference between an
> up-to-date index and a not-up-t
Bruce Momjian <[EMAIL PROTECTED]> writes:
> The attached patch warns users when they create documentation output
> that has no index, and suggests re-running 'gmake'.
This is just useless noise. If it could tell the difference between an
up-to-date index and a not-up-to-date one, there might be s
On Sat, 2007-01-06 at 22:09 -0500, Tom Lane wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> >> cost is having to fsync the whole table afterwards. So it really only
> >> makes sense for commands that one can expect are writing pretty much
> >> all of the table. I could easily see it bein
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>> cost is having to fsync the whole table afterwards. So it really only
>> makes sense for commands that one can expect are writing pretty much
>> all of the table. I could easily see it being a net loss for individual
>> INSERTs.
> What about multi
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom, on HPPA, does ERANGE get set for both overflow and underflow? I
> > assume only overflow.
>
> Yeah, AFAICT exp() just returns zero for underflow cases. I get
>
> regression=# select exp(-2000);
> ERROR: value out of range: un
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom, on HPPA, does ERANGE get set for both overflow and underflow? I
> assume only overflow.
Yeah, AFAICT exp() just returns zero for underflow cases. I get
regression=# select exp(-2000);
ERROR: value out of range: underflow
but I was getting that
> > Is there some technical reason that the INSERT statements need to use WAL
> > in
> > these scenarios?
>
> First, there's enough other overhead to an INSERT that you'd not save
> much percentagewise. Second, not using WAL doesn't come for free: the
> cost is having to fsync the whole table
Robert Treat <[EMAIL PROTECTED]> writes:
> On Saturday 06 January 2007 16:36, Simon Riggs wrote:
>
>> BEGIN;
>> CREATE TABLE foo...
>> INSERT INTO foo --uses WAL
>> COPY foo.. --no WAL
>> INSERT INTO foo --uses WAL
>> COPY foo.. --no WAL
>> INSERT INTO foo --uses WAL
>> COPY foo
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Peter Eisentraut wrote:
>> Certainly postgres has plenty of long ones. And I don't know why
> I don't see them.
postgres/postmaster accept --any-guc-variable=value. AFAIR all the
single-letter options these days are equivalent to one of those.
There'
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Simon Riggs wrote:
>> Reason for no documentation was that CREATE INDEX and CREATE TABLE AS
>> SELECT already use this optimisation, but to my knowledge neither was/is
>> documented on those command pages.
> I wasn't aware those used the optimization. S
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> The rule is: if the relfilenode for a table is new in this transaction
> (and therefore the whole things will be dropped at end-of-transaction)
> then *all* COPY commands are able to avoid writing WAL safely, if:
> - PITR is not enabled
> - there is no ac
Bruce Momjian <[EMAIL PROTECTED]> writes:
> We aren't going to disable that --- we are considering disabling the
> backend from treating it as a single transaction.
Or even more specifically, making sure that that only happens if you
explicitly put begin/commit into the -c string.
One thing I thi
On Sat, 2007-01-06 at 20:14 -0500, Bruce Momjian wrote:
> Peter Eisentraut wrote:
> > Bruce Momjian wrote:
> > > > pg_config would need short ones.
> > >
> > > Seems we should have some,
> >
> > But why? What is the use case? It's not like pg_config is a frequently
> > typed command.
>
> I tho
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Do we need a TODO for this?
Well, if we *don't* change the backend to disallow multi statements per
PQexec, then we'd probably better do something about this. If we do
make that change then it's not a problem anymore.
>> Hm, that's an interesting point
elein wrote:
> On Fri, Jan 05, 2007 at 08:45:51PM -0500, Tom Lane wrote:
> > Ron Mayer <[EMAIL PROTECTED]> writes:
> > > Tom Lane wrote:
> > >> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > >>> What value is allowing multiple queies via PQexec()
> > >>
> > >> The only argument I can think of is th
On Fri, Jan 05, 2007 at 08:45:51PM -0500, Tom Lane wrote:
> Ron Mayer <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >>> What value is allowing multiple queies via PQexec()
> >>
> >> The only argument I can think of is that it allows applications t
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > > pg_config would need short ones.
> >
> > Seems we should have some,
>
> But why? What is the use case? It's not like pg_config is a frequently
> typed command.
I thought consistency. Why do any of the commands have long and short
options?
On 7 Jan 2007 at 1:39, Oleg Bartunov wrote:
> On Sat, 6 Jan 2007, Dan Langille wrote:
>
> > On 6 Jan 2007 at 12:09, Oleg Bartunov wrote:
> >
> >> What's about spronsoring ?
> >
> > Are you asking if your and Teodor can be sponsored?
>
> yes
>
> >
> >> I and Teodor would like to present new full
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> ... why is NAMEDATALEN exported at all?)
> I think because it used to be used in libpq's notification structure.
Yeah, you're probably right. Maybe we should take it out of
postgres_ext.h and move it to pg_config_manual.h. If no
Bruce Momjian wrote:
> > pg_config would need short ones.
>
> Seems we should have some,
But why? What is the use case? It's not like pg_config is a frequently
typed command.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
Hi!
I'm trying to implement a top level node that must have a lefttree and a
righttree. The lefttree consists of a regular tree of other nodes required
for the query (that I let postgres' optimizer build on its own) and the
righttree should be a table scan (of a table called for in the FROM claus
Tom Lane wrote:
> I'm wondering how this got into the TODO list. It seems rather
> pointless, and likely to create client compatibility problems (if
> not, why is NAMEDATALEN exported at all?)
I think because it used to be used in libpq's notification structure.
--
Peter Eisentraut
http://devel
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > Added to TODO:
> >
> > * Make consistent use of long/short command options --- pg_ctl needs
> > long ones, pg_config doesn't have short ones, postgres doesn't have
> > enough long ones, etc.
>
> Certainly postgres has plenty of long ones. And
Bruce Momjian wrote:
> Added to TODO:
>
> * Make consistent use of long/short command options --- pg_ctl needs
> long ones, pg_config doesn't have short ones, postgres doesn't have
> enough long ones, etc.
Certainly postgres has plenty of long ones. And I don't know why
pg_config would need
Dhanaraj M wrote:
> Tom Lane wrote:
> > Alvaro Herrera <[EMAIL PROTECTED]> writes:
> >
> >> Dhanaraj M wrote:
> >>
> >>> I am sending the patch for the following TODO item:
> >>> Allow the identifier length to be increased via a configure option
> >>>
> >
> >
> >> You should use p
On Sat, 6 Jan 2007, Dan Langille wrote:
On 6 Jan 2007 at 12:09, Oleg Bartunov wrote:
What's about spronsoring ?
Are you asking if your and Teodor can be sponsored?
yes
I and Teodor would like to present new full text search, now built into
PostgreSQL core. We already have patch for 8.3
Added to TODO:
* Make consistent use of long/short command options --- pg_ctl needs
long ones, pg_config doesn't have short ones, postgres doesn't have
enough long ones, etc.
---
Andrew Dunstan wrote:
>
> I notice tha
I saw no replies to this.
---
Simon Riggs wrote:
> Merge Joins require us to potentially Mark and Restore positions in the
> tuples arriving from executor sub-nodes.
>
> This currently means that if the tuples arrive from a
Do we need a TODO for this?
---
Tom Lane wrote:
> Markus Schiltknecht <[EMAIL PROTECTED]> writes:
> > I've just found the stumbling block: the -c option of psql wraps all in
> > a transaction, as man psql says:
> > ...
> >
Ron Mayer wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> What value is allowing multiple queies via PQexec()
> >
> > The only argument I can think of is that it allows applications to be
> > sloppy about parsing a SQL script into individual commands before they
> > sen
Dave Page wrote:
> Bruce Momjian wrote:
> > Dave Page wrote:
> >> Bruce Momjian wrote:
> >>> The issue is that the _hold_ patches are for patches that arrived after
> >>> feature freeze. The patches that arrived after 8.2 was released don't
> >>> go in there because it might cause confusion. I al
Bruce Momjian wrote:
Dave Page wrote:
Bruce Momjian wrote:
The issue is that the _hold_ patches are for patches that arrived after
feature freeze. The patches that arrived after 8.2 was released don't
go in there because it might cause confusion. I also have to control
how quickly I push out
Dave Page wrote:
> Bruce Momjian wrote:
> > The issue is that the _hold_ patches are for patches that arrived after
> > feature freeze. The patches that arrived after 8.2 was released don't
> > go in there because it might cause confusion. I also have to control
> > how quickly I push out patches
Bruce Momjian wrote:
The issue is that the _hold_ patches are for patches that arrived after
feature freeze. The patches that arrived after 8.2 was released don't
go in there because it might cause confusion. I also have to control
how quickly I push out patches from the queue so as not to over
Simon Riggs wrote:
> > Somehow, neither of these statements seem likely to be uttered by
> > a sane DBA ...
>
> If I take a backup of a server and bring it up on a new system, the
> blocks in the backup will not have been CRC checked before they go to
> disk.
>
> If I take the same server and now
Simon Riggs wrote:
> On Sat, 2007-01-06 at 10:56 -0500, Bruce Momjian wrote:
> > Simon Riggs wrote:
> > > All have been awaiting review for at least a month (though in one case
> > > the latest version is quite recent). They probably ought to be on the
> > > hold queue; all are ready to be reviewed
Kenneth Marshall wrote:
> One problem with only putting this information in the system logs
> is that when we provide database services to a member of our
> community we do not actually give them an account of the DB server
> or log server. This means that this very useful information would
> need
On Sat, 2007-01-06 at 10:56 -0500, Bruce Momjian wrote:
> Simon Riggs wrote:
> > All have been awaiting review for at least a month (though in one case
> > the latest version is quite recent). They probably ought to be on the
> > hold queue; all are ready to be reviewed for final
> > application/re
Simon Riggs wrote:
> I'm not clear about the difference between the unapplied patches list
> and the hold list. What is the significance of the two lists?
>
> There's a number of patches submitted to pgsql-patches that don't show
> up on either list. I haven't made a list of these, but they includ
Tom Lane wrote:
"Dave Page" <[EMAIL PROTECTED]> writes:
From: Tom Lane <[EMAIL PROTECTED]>
I think forking a separate
pg_dump for each database is a perfectly fine arrangement, and should be
left alone.
Hmm, would you be happy with my original proposal to add an append option to
pg_dump?
I
I have looked over this patch, and it completes part of this TODO item:
o Add SET PERFORMANCE_TIPS option to suggest INDEX, VACUUM, VACUUM
ANALYZE, and CLUSTER
Here is the foundation of it:
For an incoming EXPLAIN command, the planner generates the plan and, if
Peter Eisentraut wrote:
Dave Page wrote:
In pgAdmin we use pg_dump's -f option to write backup files. The IO
streams are redirected to display status and errors etc. in the GUI.
In order to enhance the interface to allow backup of entire clusters
as well as role and tablespace definitions, we n
Stefan Kaltenbrunner wrote:
> Bruce Momjian wrote:
> > Log Message:
> > ---
> > Check for ERANGE in exp() as well.
>
> this broke the regression tests on a number of boxes:
>
> http://buildfarm.postgresql.org/cgi-bin/show_status.pl
>
> example:
>
> http://buildfarm.postgresql.org/cgi-bi
I wrote:
> One of the possibilities for fixing it is to add productions that
> allow table_ref to expand to NULLS_FIRST, WITH_CASCADED, and the
> other two-word pseudo-tokens, and then build the appropriate
> relation-with-alias syntax tree out of whole cloth. I find this pretty
> ugly though, and
Bruce Momjian wrote:
> Log Message:
> ---
> Check for ERANGE in exp() as well.
this broke the regression tests on a number of boxes:
http://buildfarm.postgresql.org/cgi-bin/show_status.pl
example:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=sponge&dt=2007-01-06%2015:30:02
S
Patch applied. Thanks.
---
Euler Taveira de Oliveira wrote:
> Peter Eisentraut wrote:
>
> > On the name of the option, it's not actually a "data" directory, so I'd
> > just
> > call it --xlogdir, parallel to --datadir.
Euler Taveira de Oliveira <[EMAIL PROTECTED]> writes:
> Simon Riggs wrote:
>> The enclosed patch implements this, as discussed. There is no user
>> interface to enable/disable, just as with CTAS and CREATE INDEX; no
>> docs, just code comments.
>>
> IMHO, this deserves an GUC parameter (use_wal_in
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> Presumably you could put extra grammar rules in to throw errors when you
> see FROM NULLS FIRST?
It'll throw an error just fine without any extra rules, because there
won't be any production allowing the NULLS_FIRST pseudo-token there.
You already see th
Bruce Momjian <[EMAIL PROTECTED]> writes:
> FYI, I am going need to add documentation in the COPY manual page or no
> one will know about this performance enhancement.
I don't think it belongs in COPY. What would make more sense is another
item under the "populating a database" performance tips,
"Dave Page" <[EMAIL PROTECTED]> writes:
>> From: Tom Lane <[EMAIL PROTECTED]>
>> I think forking a separate
>> pg_dump for each database is a perfectly fine arrangement, and should be
>> left alone.
> Hmm, would you be happy with my original proposal to add an append option to
> pg_dump?
I don't
Simon Riggs wrote:
> All have been awaiting review for at least a month (though in one case
> the latest version is quite recent). They probably ought to be on the
> hold queue; all are ready to be reviewed for final
> application/rejection.
>
> I'd hasten to add that none of those are mine. My pa
On Mon, 2007-01-01 at 19:04 -0500, Bruce Momjian wrote:
> I will start processing the patches held for 8.3 this week or next, now
> that the holiday break is over:
>
> http://momjian.postgresql.org/cgi-bin/pgpatches_hold
>
The following patches don't appear on this list:
Concurrent psql
On 6 Jan 2007 at 12:09, Oleg Bartunov wrote:
> What's about spronsoring ?
Are you asking if your and Teodor can be sponsored?
> I and Teodor would like to present new full text search, now built into
> PostgreSQL core. We already have patch for 8.3 and current
> documentation is available
> http
On Fri, 2007-01-05 at 22:57 -0500, Tom Lane wrote:
> Jim Nasby <[EMAIL PROTECTED]> writes:
> > On Jan 5, 2007, at 6:30 AM, Zeugswetter Andreas ADI SD wrote:
> >> Ok, so when you need CRC's on a replicate (but not on the master) you
>
> > Which sounds to me like a good reason to allow the option in
Dave Page wrote:
> In pgAdmin we use pg_dump's -f option to write backup files. The IO
> streams are redirected to display status and errors etc. in the GUI.
>
> In order to enhance the interface to allow backup of entire clusters
> as well as role and tablespace definitions, we need to be able to
On Fri, 2007-01-05 at 20:19 -0500, Tom Lane wrote:
> The only other solution I can see is to make use of the lookahead filter
> we already have in filtered_base_yylex() to combine NULLS FIRST and
> NULLS LAST into single tokens. This is not an ideal solution: consider
>
> SELECT * FROM nul
What's about spronsoring ? I and Teodor would like to present
new full text search, now built into PostgreSQL core.
We already have patch for 8.3 and current documentation is available
http://mira.sai.msu.su/~megera/pgsql/ftsdoc/
Oleg
On Fri, 5 Jan 2007, Dan Langille wrote:
I have the pleasur
> --- Original Message ---
> From: Tom Lane <[EMAIL PROTECTED]>
> To: Dave Page <[EMAIL PROTECTED]>
> Sent: 1/5/07, 10:52:37 PM
> Subject: Re: [HACKERS] -f option for pg_dumpall
>
> I think this will be an exercise in time-wasting, and very possibly
> destabilize *both* tools. pg_dump
> --- Original Message ---
> From: Tom Lane <[EMAIL PROTECTED]>
> To: Dave Page <[EMAIL PROTECTED]>
> Sent: 1/5/07, 10:48:17 PM
> Subject: Re: [HACKERS] -f option for pg_dumpall
>
>
> Wouldn't it be easier/better to re-point stdout at the -f file, and not
> touch pg_dump at all?
First
62 matches
Mail list logo
