On Tue, Aug 19, 2008 at 9:40 PM, Tom Lane [EMAIL PROTECTED] wrote:
Robert Treat [EMAIL PROTECTED] writes:
I'd still like to see us adopt the proposal from some time ago where
we stop commenting out the parameters at all, but short of that,
hiding options seems about the worst choice we could
Peter Eisentraut wrote:
If you replace the third point by maybe partition TOAST tables, replace
large object handle by TOAST pointer, and create an API to work on TOAST
pointers, how are the two so much different? And why should they be? I can
see that there are going to be needs to access
Alvaro Herrera wrote:
Dave Page wrote:
On Tue, Aug 19, 2008 at 10:03 PM, Tom Lane [EMAIL PROTECTED] wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Hmm, let me suggest providing it as a manpage for postgresql.conf, i.e.,
you run man postgresql.conf and it gives you this manpage documenting
On Wed, Aug 20, 2008 at 4:40 AM, Joshua Drake [EMAIL PROTECTED] wrote:
On Tue, 19 Aug 2008 23:32:34 -0400
Tom Lane [EMAIL PROTECTED] wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
On idea is for postgresql.conf to merely include other files:
include 'sharedmem.conf'
include
Am 19.08.2008 um 20:47 schrieb Tom Lane:
Bruce Momjian [EMAIL PROTECTED] writes:
Joshua Drake wrote:
Is our backpatch policy documented? It does not appear to be in
developer FAQ.
Seems we need to add it.
I'm not sure that I *want* a formal written-down backpatch policy.
Whether (and
Peter Eisentraut wrote:
On Tuesday 19 August 2008 19:12:16 Tom Lane wrote:
Well, why not just make a one-eighty and say that the default
postgresql.conf is *empty* (except for whatever initdb puts into it)?
Well, my original implementation of GUC had an empty default
configuration
file,
Le mercredi 20 août 2008, Tom Lane a écrit :
That just begs the question of what's the difference between a bug and
a limitation. AFAICS, having such a policy/guideline/whatchacallit
in place wouldn't have done a single thing to stop the current flamewar,
because the people who want this
On Wed, 2008-08-20 at 10:46 +0900, ITAGAKI Takahiro wrote:
One thing to worry about is a confliction of RmgrId. We can check
conflictions in redo because rmgrs are actually registered, but
we might need to check conflictions even in a normal running.
Extensions that write own XLog record can
On Tue, 2008-08-19 at 19:45 -0400, Tom Lane wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
If there is plan invalidation then you just change called1() to return
one more field and that's it - no juggling with C) and D) and generally
less things that can go wrong.
That is a pure flight
Earlier we saw some bug reports from someone who had a buffer flush fail do to
ENOSPC. We asserted then that that should never happen because when we extend
the relation we write out the new blocks so any ENOSPC errors out to happen at
that point, not when a buffer is flushed.
However looking at
Hello
I understand now why Oracle use = symbol for named params. This isn't
used so operator - so implementation is trivial.
postgres=# create function x(a boolean) returns bool as $$select $1$$
language sql;
CREATE FUNCTION
Time: 5,549 ms
postgres=# select x(a = true);
x
---
t
(1 row)
Time:
* Gregory Stark:
On Unix that creates a sparse file where the intervening blocks are
not allocated. When we later write out those blocks the filesystem
then has to allocate space for them.
This seems to happen relatively rarely. Creating temporary holes like
this usually results in heavily
Gregory Stark napsal(a):
On Unix that creates a sparse file where the intervening blocks are not
allocated. When we later write out those blocks the filesystem then has to
allocate space for them. IIRC the bug reports were from Windows. I'm not sure
what NTFS's behaviour with sparse files is.
Gregory Stark wrote:
Now this only matters if we ever call mdextend on a block which isn't the
block immediately following the end of file. Is that true?
I don't think so.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list
The lack of plan invalidation is limitation that also has two bugs attached
to it.
I agree that full fledged patch to fix all the isssues should not be done in
8.3.
I can't agree that effort to get the bugs fixed already in 8.3 should not be
made.
I can understand that hackers here have learned to
Gregory Stark [EMAIL PROTECTED] writes:
Now this only matters if we ever call mdextend on a block which isn't the
block immediately following the end of file. Is that true?
Only in hash indexes.
regards, tom lane
--
Sent via pgsql-hackers mailing list
Pavel Stehule [EMAIL PROTECTED] writes:
I understand now why Oracle use = symbol for named params. This isn't
used so operator - so implementation is trivial.
You really didn't understand the objection at all, did you?
The point is not about whether there is any built-in operator named =.
The
Dave Page wrote:
On Wed, Aug 20, 2008 at 4:40 AM, Joshua Drake [EMAIL PROTECTED] wrote:
I am not arguing for this but if we went down that route it does buy us
the ability to compartmentalize the entire conf.. so you have:
memory_settings.conf
logging.conf
maintenance.conf
Would
Peter Eisentraut wrote:
If you replace the third point by maybe partition TOAST tables, replace
large object handle by TOAST pointer, and create an API to work on TOAST
pointers, how are the two so much different? And why should they be?
The reason they should be different is that (IMHO
Alvaro Herrera wrote:
Dave Page wrote:
On Wed, Aug 20, 2008 at 4:40 AM, Joshua Drake [EMAIL PROTECTED] wrote:
I am not arguing for this but if we went down that route it does buy us
the ability to compartmentalize the entire conf.. so you have:
memory_settings.conf
logging.conf
On Wed, Aug 20, 2008 at 03:12:43PM +0300, Asko Oja wrote:
- If there is nothing that can be done in 8.3 at least warning should be
added into the documentation. It will be just one more don't in our long
list don'ts for our developers.
I am in favour of that change in the 8.3 branch.
On Wed, Aug 20, 2008 at 09:16:56AM -0400, Andrew Sullivan wrote:
On Wed, Aug 20, 2008 at 03:12:43PM +0300, Asko Oja wrote:
- If there is nothing that can be done in 8.3 at least warning should be
added into the documentation. It will be just one more don't in our long
list don'ts for our
2008/8/20 Tom Lane [EMAIL PROTECTED]:
Pavel Stehule [EMAIL PROTECTED] writes:
I understand now why Oracle use = symbol for named params. This isn't
used so operator - so implementation is trivial.
You really didn't understand the objection at all, did you?
The point is not about whether
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Well, there seems to be a very substantial body of opinion that says
we *do* need to hide uninteresting options.
more to the point... not just uninteresting but dangerous for the
uninformed ones...
i have seen to many people turning off
Asko Oja wrote:
I do get the impression that Tom who would prefer to get all the pl's
out of PostgreSQL and live happily ever after with pure SQL standard.
I have not seen the slightest evidence of this, and don't believe it for
a minute.
I understand some of the frustration you are
Asko Oja escribió:
In the first message Martin asked
There are probably a lot of details that I have overlooked. I'd be really
thankful for some constructive comments and criticism. Especially, what
needs
to be done to have this in the core. Feedback appreciated.
Can we get back to the
Thanks for a nice replay Andrew.
So best solution for 8.3 is update pg_proc set proname = proname; whenever
you need to drop and create functions or some in house patch.
Lets get on with 8.4
Asko
On Wed, Aug 20, 2008 at 4:16 PM, Andrew Sullivan [EMAIL PROTECTED]wrote:
On Wed, Aug 20, 2008 at
Hm, shouldn't this query notice that random() is volatile and not make the
subquery an initplan?
postgres=# select i, (select (random()*1000)::integer ) from x limit 5;
i | ?column?
---+--
1 | 677
2 | 677
3 | 677
4 | 677
5 | 677
(5 rows)
postgres=#
Hi,
It seems we're neglecting to copy GNUmakefile into the temporary
distdir:
$ pwd
/pgsql/build/83_rel
$ make dist
rm -rf postgresql-8.3.3* =install=
for x in `cd /pgsql/source/83_rel find . -name CVS -prune -o -print`; do \
file=`expr X$x : 'X\./\(.*\)'`; \
if test -d
Alvaro Herrera [EMAIL PROTECTED] writes:
This is where the interesting questions are:
http://archives.postgresql.org/message-id/10333.1219179364%40sss.pgh.pa.us
Upthread, someone speculated about solving the problem by forcing plan
cache flush on *any* catalog change. I think that's probably
Gregory Stark [EMAIL PROTECTED] writes:
Hm, shouldn't this query notice that random() is volatile and not make the
subquery an initplan?
We've never done that in the past; in fact I recall seeing people using
subselects deliberately to hide volatility.
regards, tom lane
Is it sensible for make dist to work in a VPATH? Seems like the entire
point of that operation is to modify the source tree.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
David Fetter napsal(a):
On Tue, Aug 19, 2008 at 09:50:53PM -0400, Tom Lane wrote:
David Fetter [EMAIL PROTECTED] writes:
On Tue, Aug 19, 2008 at 07:45:16PM -0400, Tom Lane wrote:
FWIW, given that there will probably always be corner cases. I can
see the attraction in Simon's suggestion of
On Wednesday 20 August 2008 02:22:26 Jaime Casanova wrote:
On Tue, Aug 19, 2008 at 9:40 PM, Tom Lane [EMAIL PROTECTED] wrote:
Robert Treat [EMAIL PROTECTED] writes:
I'd still like to see us adopt the proposal from some time ago where
we stop commenting out the parameters at all, but short
Greg Sabino Mullane [EMAIL PROTECTED] writes:
# foobar: Adjusts the foobariness of the database
#
# This uses units of baz from 1-10, with 10 being the strongest
#
# Changing this setting requires a reload
# This setting may also be changed per session
# The default value is 5
#
# For
Tom Lane wrote:
Is it sensible for make dist to work in a VPATH? Seems like the entire
point of that operation is to modify the source tree.
Actually the point AFAICS is to generate a tarball. Why wouldn't it
work in a VPATH build?
--
Alvaro Herrera
On Wed, 2008-08-20 at 08:50 -0400, Andrew Dunstan wrote:
Asko Oja wrote:
I do get the impression that Tom who would prefer to get all the pl's
out of PostgreSQL and live happily ever after with pure SQL standard.
I have not seen the slightest evidence of this, and don't believe it
2008/8/1 David Fetter [EMAIL PROTECTED]:
On Thu, Jul 31, 2008 at 11:00:15PM +0900, Hitoshi Harada wrote:
2008/7/31 David Fetter [EMAIL PROTECTED]:
Sorry about that. Apparently, at least the way things are set up,
there's a *lot* of history you can rewind. Further changes should
move
I try to understand why HeapTupleHeaderData structure has t_datum
member. This is use only on few places and from my point of view this
information should be stored in the HeapTupleData structure or split
HeapTupleHeaderData it into two structures (DatumTupleHeaderData). The
idea behind my
Zdenek Kotala [EMAIL PROTECTED] writes:
I try to understand why HeapTupleHeaderData structure has t_datum
member. This is use only on few places and from my point of view this
information should be stored in the HeapTupleData structure or split
HeapTupleHeaderData it into two structures
On Wed, Aug 20, 2008 at 05:03:19PM +0300, Asko Oja wrote:
Lets get on with 8.4
Oh, I shoulda mentioned that, too -- I completely support doing this
work for 8.4. (I can think of more than one case where this feature
alone would be worth the upgrade.)
A
--
Andrew Sullivan
[EMAIL PROTECTED]
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
So your plan is that postgresql.conf will be approximately two thousand
lines long, before the user has ever touched it at all? (Two hundred
or so GUC variables and ten lines of comments for each one)
Sure, why not? Clarity should always
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
One more benefit of a small file is that it makes it easier to ask someone
please attach a copy of your postgresql.conf file; rather than please
send the output of grep -v '^[]*#' postgresql.conf | grep = or worse
Can you recall what
Alvaro Herrera wrote:
It seems we're neglecting to copy GNUmakefile into the temporary
distdir:
make -C postgresql-8.3.3 distprep
make[1]: entrant dans le répertoire «
/home/alvherre/Code/CVS/pgsql/build/83_rel/postgresql-8.3.3 » make[1]: ***
Pas de règle pour fabriquer la cible « distprep
On Wed, 20 Aug 2008 15:49:39 -
Greg Sabino Mullane [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Sure, why not? Clarity should always trump brevity. The only people
who gain from a comment-less file are the ones who are already expert
in it.
You are
Greg Sabino Mullane [EMAIL PROTECTED] writes:
So your plan is that postgresql.conf will be approximately two thousand
lines long, before the user has ever touched it at all? (Two hundred
or so GUC variables and ten lines of comments for each one)
Sure, why not? Clarity should always trump
On Wed, Aug 20, 2008 at 09:08:02AM -0700, Joshua D. Drake wrote:
On Wed, 20 Aug 2008 15:49:39 -
Greg Sabino Mullane [EMAIL PROTECTED] wrote:
Sure, why not? Clarity should always trump brevity. The only
people who gain from a comment-less file are the ones who are
already expert in
Hi,
Thanks to Brendan Jurd, who spent a lot of effort in creating useful
Mediawiki templates, we now have moved the TODO list to the Wiki site.
The new official location for the TODO list is here:
http://wiki.postgresql.org/wiki/Todo:Todo
I hereby kindly request the WWW team to update any
On Aug 18, 2008, at 11:49 AM, Tom Lane wrote:
Perhaps what's also needed here is to measure just how accurate
the cpu_*
costs are. Perhaps they need to be raised somewhat if we're
underestimating
the cost of digging through 200 tuples on a heap page and the
benefit of a
binary search on
On Wed, 20 Aug 2008 13:12:15 -0400
Alvaro Herrera [EMAIL PROTECTED] wrote:
The move has been approved by Bruce, the current maintainer. I hope
that he continues to maintain the new version.
This is great! I only have one small request. The font is really small
and I have pretty good
Joshua Drake wrote:
On Wed, 20 Aug 2008 13:12:15 -0400
Alvaro Herrera [EMAIL PROTECTED] wrote:
The move has been approved by Bruce, the current maintainer. I hope
that he continues to maintain the new version.
This is great! I only have one small request. The font is really small
Alvaro Herrera wrote:
Hi,
Thanks to Brendan Jurd, who spent a lot of effort in creating useful
Mediawiki templates, we now have moved the TODO list to the Wiki site.
The new official location for the TODO list is here:
http://wiki.postgresql.org/wiki/Todo:Todo
I hereby kindly request
Kevin Grittner [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] wrote:
[ complicated scheme for improving planning of EXISTS ]
So I'd be very happy to see this work done, not because I can't find a
workaround, but because trying to teach all the programmers tricky
hand-optimizations is
Alvaro Herrera wrote:
Hi,
Thanks to Brendan Jurd, who spent a lot of effort in creating useful
Mediawiki templates, we now have moved the TODO list to the Wiki site.
Yay!
Thanks to Brendan for helping out with that!
The new official location for the TODO list is here:
Folks,
I've noticed that neither SHOW ALL nor SELECT ... FROM pg_settings
shows the value of custom GUCs, even though SHOW will do so for any
given one. For example:
SHOW plperl.use_strict;
plperl.use_strict
---
true
(1 row)
SELECT * FROM pg_settings WHERE name =
On Wed, Aug 20, 2008 at 10:26:11AM -0700, Joshua D. Drake wrote:
On Wed, 20 Aug 2008 13:12:15 -0400
Alvaro Herrera [EMAIL PROTECTED] wrote:
The move has been approved by Bruce, the current maintainer. I
hope that he continues to maintain the new version.
This is great! I only have one
David Fetter [EMAIL PROTECTED] writes:
I've noticed that neither SHOW ALL nor SELECT ... FROM pg_settings
shows the value of custom GUCs, even though SHOW will do so for any
given one.
Yeah, that's intentional, because what the code is designed to do is
allow GUC values for a user-written
On Wed, 20 Aug 2008 10:53:57 -0700
David Fetter [EMAIL PROTECTED] wrote:
This is great! I only have one small request. The font is really
small and I have pretty good eyesight.
Fixed :)
Much better, thanks!
Joshua D. Drake
Cheers,
David.
--
The PostgreSQL Company since 1997:
Bruce Momjian [EMAIL PROTECTED] writes:
I believe TODO and TODO.html files should now be removed from CVS.
+1. Leaving them in CVS would just result in confusion.
It might make sense to leave TODO still in the file set, but reduce its
content to a pointer to the wiki page.
Magnus Hagander [EMAIL PROTECTED] writes:
And let's keep the version in CVS around for a couple of days to let
things settle before we do a cvs remove on it..
Why? cvs remove is reversible, if it comes to that.
regards, tom lane
--
Sent via pgsql-hackers mailing list
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
And let's keep the version in CVS around for a couple of days to let
things settle before we do a cvs remove on it..
Why? cvs remove is reversible, if it comes to that.
Good pt. I was mixing it up with the sucky way cvs deals with
Idly thumbing through the new TODO list, I noticed that the second item
from the bottom (about how we don't want optional AS) has been
superseded by events ...
http://archives.postgresql.org/pgsql-committers/2008-02/msg00172.php
regards, tom lane
--
Sent via
Tom Lane wrote:
Idly thumbing through the new TODO list, I noticed that the second item
from the bottom (about how we don't want optional AS) has been
superseded by events ...
http://archives.postgresql.org/pgsql-committers/2008-02/msg00172.php
Good point, removed. I didn't mark it as done
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I believe TODO and TODO.html files should now be removed from CVS.
+1. Leaving them in CVS would just result in confusion.
It might make sense to leave TODO still in the file set, but reduce its
content to a pointer to the wiki
On Wed, Aug 20, 2008 at 01:56:50PM -0400, Tom Lane wrote:
David Fetter [EMAIL PROTECTED] writes:
I've noticed that neither SHOW ALL nor SELECT ... FROM pg_settings
shows the value of custom GUCs, even though SHOW will do so for
any given one.
Yeah, that's intentional, because what the
I have added this email's URL to TODO under tuple visibility.
---
Karl Schnaitter wrote:
Sometime last year, a discussion started about including visibility
metadata to avoid heap fetches during an index scan:
Peter Eisentraut wrote:
Fix option 1 would be to copy the build tree as well, if it is different from
the source tree. Since the build tree contains a bunch of symlinks back to
the source tree, this would probably need some careful file handling to not
overwrite the real files with
Tom Lane [EMAIL PROTECTED] wrote:
when we have an EXISTS that could be done both ways,
why not just generate plans for both ways, and leave the decision
which to use until later?
That seems good to me. The costs for the slower plan generally come
out much higher. When the run times are
Another technique that we could play with is to have the
AlternativeSubPlans node track the actual number of calls it gets,
and switch from the retail implementation to the hashed
implementation if that exceeds a threshold. This'd provide some
robustness in the face of bad estimates,
Anyone knows a link that has some docs about how to get that setup ?
Also is it stable enough for production ?
I though getting postgreSQL from CVS and compiling was not such a good
idea since the CVSROOT is probably not stable, is that wrong ?
since I could not find info out there this is
Marcelo Martins wrote:
Anyone knows a link that has some docs about how to get that setup ?
Also is it stable enough for production ?
I though getting postgreSQL from CVS and compiling was not such a good
idea since the CVSROOT is probably not stable, is that wrong ?
since I could not find
71 matches
Mail list logo
