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
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
> 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,
>>> 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
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
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
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
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
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
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:
> 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
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
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.
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
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, 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
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
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
"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.
>
> The new official location for the TODO list is here:
> http://wiki.postgresql.org/wiki/Todo:Todo
>
> I hereby kindly r
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
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
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
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 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
"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, 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
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
-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
-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
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]
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
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
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
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
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
"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
> #
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,
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
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
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
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
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
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
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
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
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
-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
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
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
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.
>
>
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
> 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
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
"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 =
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
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 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
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:
> 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
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
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
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
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
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
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
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
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'
>>
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
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
70 matches
Mail list logo
