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 acce
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
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'
>>
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 h
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, whi
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 th
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
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 pur
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 (pgsql-hacker
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 (pgsql-hacker
"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 =
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.c
> 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
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
>>> log
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
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 ab
-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 t
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 fee
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
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
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=# expl
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 "/p
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 probabl
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 l
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:
http://www.postgresq
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 pr
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,
"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
> #
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 Herrerahttp://ww
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 b
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 s
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 ques
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 structure
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 rec
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 « dist
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
"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 alway
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 e
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 refere
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 the
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 eyesi
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 reall
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 r
"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-optim
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:
> http://wiki.p
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" = 'plperl.us
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
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
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 maili
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
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 pgsql-hackers
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 don
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
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 w
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:
>
> http
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 sym
>>> 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 tim
> 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 wh
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 in
70 matches
Mail list logo
