On Wed, 2009-05-20 at 23:01 -0400, Zdenek Kotala wrote:
We use default one. I did not tested difference between them, but IIRC
that Jignesh did some testing with umem. I will ask him. However if you
give me test scenario I can test it.
Talk with Dimitri from Sun who is doing scalability
Peter Eisentraut wrote:
Note that applying this patch would introduce a double-translation issue of
the sort that you had complained about a while ago. I'm unsure which way to
proceed here.
Hmm, the patch looks fine to me. The strings are marked with
gettext_noop() in the array, and passed
Hello.
PostgreSQL is very fast when we perform (even on a huge table)
ALTER TABLE ... ADD COLUMN ... NULL;
(nullable without a default value). This is because of NULL bitmap in
tuples. And it's greatest feature for a developer!
But another very common-case query like
ALTER TABLE ... ADD
On Thursday 21 May 2009 11:06:29 Dmitry Koterov wrote:
1. Store the DEFAULT flag directly in NULL BITMAP (add a bit to NULL bitmap
not only for NULLable fields, but also for NOT NULL DEFAULT ... fields).
2. Add another bitmap for each tuple (DEFAULT bitmap). Bit value 0 means
that there is a
On Thursday 21 May 2009 10:01:59 Heikki Linnakangas wrote:
Peter Eisentraut wrote:
Note that applying this patch would introduce a double-translation issue
of the sort that you had complained about a while ago. I'm unsure which
way to proceed here.
Hmm, the patch looks fine to me. The
On Thu, May 21, 2009 at 12:06:29PM +0400, Dmitry Koterov wrote:
ALTER TABLE ... ADD COLUMN ... NULL;
(nullable without a default value). This is because of NULL bitmap in
tuples. And it's greatest feature for a developer!
I don't think this is because of the NULL bitmap. PG just never needs
Peter Eisentraut pete...@gmx.net writes:
On Thursday 21 May 2009 10:01:59 Heikki Linnakangas wrote:
Hmm, the patch looks fine to me. The strings are marked with
gettext_noop() in the array, and passed through _() when used in errmsg.
But his patch changes that to
errhint(%s,
(In most cases NOT NULL DEFAULT xxx fields are BOOLEAN, flags: it is not
handy to have 3-way flags.)
This is certainly not true for me. I have both nullable booleans and
not-nullable, defaulted columns of other types.
So, are there plans to optimize such kind of queries? This could be done
Robert Haas robertmh...@gmail.com writes:
We currently have a (really handy) facility to pull a message from the
archives by message-ID, eg:
http://archives.postgresql.org/message-id/603c8f070905202040v66cd3054t434c0b73aa844...@mail.gmail.com
Could we possibly get a similar type of link that
Josh Berkus j...@agliodbs.com writes:
Robert,
It appears that this statement has been in our documentation since Tom
Lane added FROM_COLLAPSE_LIMIT (back then, it was capitalized) on
January 25, 2003 (9bf97ff426de9), but I can't find any justification
for it anywhere. I think we either need
On Thu, May 21, 2009 at 7:50 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Josh Berkus j...@agliodbs.com writes:
Robert,
It appears that this statement has been in our documentation since Tom
Lane added FROM_COLLAPSE_LIMIT (back then, it was capitalized) on
January 25, 2003 (9bf97ff426de9), but I
On Thursday 21 May 2009 14:29:51 Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
On Thursday 21 May 2009 10:01:59 Heikki Linnakangas wrote:
Hmm, the patch looks fine to me. The strings are marked with
gettext_noop() in the array, and passed through _() when used in errmsg.
But
Hi all,
last version of psql is broken:
psql (8.4beta1, server 8.3.7)
WARNING: psql version 8.4, server version 8.3.
Some psql features might not work.
Type help for help.
postgres=# \d test
ERROR: syntax error at or near ,
LINE 1: ...index, relhasrules, reltriggers 0, relhasoids,
Having just raised the statistics targets I wonder if we should look
at raising these two parameters too. The experience on the lists are
that when people run into either of these two limits we recommend
raising them and we've never seen anyone come back complaining that
their planning time goes
On Thu, May 21, 2009 at 8:51 AM, Greg Stark st...@enterprisedb.com wrote:
Having just raised the statistics targets I wonder if we should look
at raising these two parameters too. The experience on the lists are
that when people run into either of these two limits we recommend
raising them and
Zdenek Kotala wrote:
last version of psql is broken:
psql (8.4beta1, server 8.3.7)
WARNING: psql version 8.4, server version 8.3.
Some psql features might not work.
Type help for help.
postgres=# \d test
ERROR: syntax error at or near ,
LINE 1: ...index, relhasrules, reltriggers 0,
Sam Mason s...@samason.me.uk writes:
On Thu, May 21, 2009 at 12:06:29PM +0400, Dmitry Koterov wrote:
ALTER TABLE ... ADD COLUMN ... NULL;
(nullable without a default value). This is because of NULL bitmap in
tuples. And it's greatest feature for a developer!
I don't think this is because
On Thu, May 21, 2009 at 10:45 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Sam Mason s...@samason.me.uk writes:
On Thu, May 21, 2009 at 12:06:29PM +0400, Dmitry Koterov wrote:
ALTER TABLE ... ADD COLUMN ... NULL;
(nullable without a default value). This is because of NULL bitmap in
tuples. And
On Thu, May 21, 2009 at 3:45 PM, Tom Lane t...@sss.pgh.pa.us wrote:
All that needs to be tracked is the first default value (this is
currently assumed to be NULL).
You're being a bit vague, but in any case I don't think it can work
for non-constant defaults (consider DEFAULT NOW()). And
Heikki Linnakangas píše v čt 21. 05. 2009 v 16:53 +0300:
Zdenek Kotala wrote:
last version of psql is broken:
psql (8.4beta1, server 8.3.7)
WARNING: psql version 8.4, server version 8.3.
Some psql features might not work.
Type help for help.
postgres=# \d test
ERROR:
Greg Stark st...@enterprisedb.com writes:
Schemes like this have been discussed before but I don't think we
considered applying the limitation that only the first default value
would be covered. We always wanted to be able to handle new defaults
or making a non-null column nullable later.
On Thu, May 21, 2009 at 11:13 AM, Greg Stark st...@enterprisedb.com wrote:
On Thu, May 21, 2009 at 3:45 PM, Tom Lane t...@sss.pgh.pa.us wrote:
All that needs to be tracked is the first default value (this is
currently assumed to be NULL).
You're being a bit vague, but in any case I don't
On Thu, May 21, 2009 at 4:22 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Greg Stark st...@enterprisedb.com writes:
Schemes like this have been discussed before but I don't think we
considered applying the limitation that only the first default value
would be covered. We always wanted to be able to
Greg Stark st...@enterprisedb.com writes:
On Thu, May 21, 2009 at 4:22 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Yeah ... I don't see exactly what it would buy to restrict it to just
the first such value.
Well it wouldn't buy you steady-state space savings or performance
improvements.
What
Hello,
This patch is intended to supplement Pavel's patch for named and mixed
notation support in 8.5. This patch makes it so a plpgsql function can
call another function with the same parameter names using the named
parameters notation. Without this patch, the following example will
Steve Prentice prent...@cisco.com writes:
This patch is intended to supplement Pavel's patch for named and mixed
notation support in 8.5. This patch makes it so a plpgsql function can
call another function with the same parameter names using the named
parameters notation.
Well,
--
Greg
On 21 May 2009, at 12:26, Tom Lane t...@sss.pgh.pa.us wrote:
Greg Stark st...@enterprisedb.com writes:
On Thu, May 21, 2009 at 4:22 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Yeah ... I don't see exactly what it would buy to restrict it to
just
the first such value.
Well it
On May 21, 2009, at 10:52 AM, Tom Lane wrote:
It's probably time to bite the bullet and redo the parser as has been
suggested in the past, ie fix things so that the main parser is used.
Ideally I'd like to switch the name resolution priority to be more
Oracle-like, but even if we don't do that
The patch adds the AS keyword to the plpgsql grammar and doesn't
assign an expression parameter to the sql construct if the scalar
follows the AS keyword.
Would it be possible to also support = as well as as? I believe
that SQL Server uses = exclusively, and supporting that syntax would
2009/5/21 Josh Berkus j...@agliodbs.com:
The patch adds the AS keyword to the plpgsql grammar and doesn't
assign an expression parameter to the sql construct if the scalar
follows the AS keyword.
Would it be possible to also support = as well as as? I believe that
SQL Server uses =
2009/5/21 Pavel Stehule pavel.steh...@gmail.com:
2009/5/21 Josh Berkus j...@agliodbs.com:
The patch adds the AS keyword to the plpgsql grammar and doesn't
assign an expression parameter to the sql construct if the scalar
follows the AS keyword.
Would it be possible to also support = as well
= is more common than as for sure, but this has been talked about
before starting at about this message:
http://archives.postgresql.org/message-id/14319.1228833...@sss.pgh.pa.us
-Steve
On May 21, 2009, at 11:51 AM, Josh Berkus wrote:
The patch adds the AS keyword to the plpgsql grammar
Josh Berkus wrote:
The patch adds the AS keyword to the plpgsql grammar and doesn't
assign an expression parameter to the sql construct if the scalar
follows the AS keyword.
Would it be possible to also support = as well as as? I believe
that SQL Server uses = exclusively, and supporting
33 matches
Mail list logo
