On 4 August 2011 18:57, Peter Eisentraut pete...@gmx.net wrote:
Have you considered just cataloging NOT NULL constraints as CHECK
constraints and teaching the reverse parser to convert x CHECK (x IS
NOT NULL) to x NOT NULL. It seems to me that we're adding a whole
lot of hoopla here that is
On 6 August 2011 01:01, Peter Eisentraut pete...@gmx.net wrote:
Before embarking on rewriting this patch from scratch, I would like to
know what's your opinion (or the SQL standard's) on the fact that this
patch separated the PRIMARY KEY from NOT NULL constraints, so that they
don't act
On 6 August 2011 08:17, Dean Rasheed dean.a.rash...@gmail.com wrote:
The current behaviour is inconsistent - the not-null property of a PK
is sometimes inherited and sometimes not, depending on whether the PK
is added at table-creation time or later.
Oops, that should have been depending on
On 06.08.2011 06:32, Gokulakannan Somasundaram wrote:
However, for small operations it's a net loss - you avoid writing a WAL
record, but you have to fsync() the heap instead. If you only modify a few
rows, the extra fsync (or fsyncs if there are indexes too) is more expensive
than writing the
On lör, 2011-08-06 at 08:04 +0100, Dean Rasheed wrote:
On 4 August 2011 18:57, Peter Eisentraut pete...@gmx.net wrote:
Have you considered just cataloging NOT NULL constraints as CHECK
constraints and teaching the reverse parser to convert x CHECK (x IS
NOT NULL) to x NOT NULL. It seems to
On lör, 2011-08-06 at 08:17 +0100, Dean Rasheed wrote:
The current behaviour is inconsistent - the not-null property of a PK
is sometimes inherited and sometimes not, depending on whether the PK
is added at table-creation time or later. So a change in either
direction is a change to some
On Sat, Aug 6, 2011 at 4:16 AM, Bruce Momjian br...@momjian.us wrote:
Well, if the table is created in the same transaction (which is the only
case under consideration), no other sessions can write to the table so
you are just writing the entire table on commit, rather than to the WAL.
Below
On 6 August 2011 11:03, Peter Eisentraut pete...@gmx.net wrote:
On lör, 2011-08-06 at 08:04 +0100, Dean Rasheed wrote:
On 4 August 2011 18:57, Peter Eisentraut pete...@gmx.net wrote:
Have you considered just cataloging NOT NULL constraints as CHECK
constraints and teaching the reverse parser
On 5 August 2011 20:07, Tom Lane t...@sss.pgh.pa.us wrote:
This patch is a truly horrid idea, as it eliminates the error checking
the compiler is trying to provide, and does so globally not only in the
trouble spots.
I think that the mistake I may have made here was assuming that the
existing
Dean Rasheed dean.a.rash...@gmail.com writes:
[ wonders what psql's \d will do with NOT NULL constraints ]
I think this might be taking the notion of it should be backwards
compatible too far. We're not expecting this patch to not change
the wording of error messages, for instance (in fact, I
On 06.08.2011 13:13, Simon Riggs wrote:
I think we should remove the COPY optimisation because of this and
definitely not extend INSERT SELECT to perform it automatically.
It can be very helpful when loading a lot of data, so I'm not in favor
of removing it altogether. Maybe WAL-log the first
On Sat, Aug 6, 2011 at 11:05 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 06.08.2011 13:13, Simon Riggs wrote:
I think we should remove the COPY optimisation because of this and
definitely not extend INSERT SELECT to perform it automatically.
It can be very helpful
Heikki Linnakangas wrote:
On 06.08.2011 13:13, Simon Riggs wrote:
I think we should remove the COPY optimisation because of this and
definitely not extend INSERT SELECT to perform it automatically.
It can be very helpful when loading a lot of data, so I'm not in
favor of removing it
Jaime Casanova ja...@2ndquadrant.com writes:
On Sat, Aug 6, 2011 at 11:05 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
It can be very helpful when loading a lot of data, so I'm not in favor of
removing it altogether. Maybe WAL-log the first 1 rows or such normally,
Hello,
I am working on a PostgreSQL extension module which defines new
grammar rules completing the classical SQL syntax defined in the
src/backend/parser/gram.y file.
Basically, I want to handle predicates having an infixed syntax { X IS
Y } and rewrite them as classical Boolean functions with
Thomas Girault toma.gira...@gmail.com writes:
func_expr:
...
| func_arg_expr IS func_name over_clause
However, my first attempt leads to the following errors :
/usr/bin/bison -d -o gram.c gram.y
gram.y: conflicts: 84 shift/reduce, 807 reduce/reduce
gram.y: expected
On Wed, Aug 3, 2011 at 11:21 AM, Robert Haas robertmh...@gmail.com wrote:
About nine months ago, we had a discussion of some benchmarking that
was done by the mosbench folks at MIT:
http://archives.postgresql.org/pgsql-hackers/2010-10/msg00160.php
Although the authors used PostgreSQL as a
On Fri, 2011-08-05 at 23:16 -0400, Bruce Momjian wrote:
Well, if the table is created in the same transaction (which is the only
case under consideration), no other sessions can write to the table so
you are just writing the entire table on commit, rather than to the WAL.
The transaction can
On Wed, Aug 3, 2011 at 3:21 PM, Jim Nasby j...@nasby.net wrote:
On Aug 3, 2011, at 1:21 PM, Robert Haas wrote:
1. We configure PostgreSQL to use a 2 Gbyte application-level cache
because PostgreSQL protects its free-list with a single lock and thus
scales poorly with smaller caches. This is a
Robert Haas robertmh...@gmail.com writes:
It would be nice if the Linux guys would fix this problem for us, but
I'm not sure whether they will. For those who may be curious, the
problem is in generic_file_llseek() in fs/read-write.c. On a platform
with 8-byte atomic reads, it seems like it
Tom Lane t...@sss.pgh.pa.us writes:
I think we'll be a lot better off with the framework discussed last
year: build a generic plan, as well as custom plans for the first few
sets of parameter values, and then observe whether there's a significant
reduction in estimated costs for the custom
On Fri, Aug 5, 2011 at 08:53, Andrew Dunstan and...@dunslane.net wrote:
On 08/04/2011 11:23 PM, Alex Hunsaker wrote:
[ ... don't let people set signal handlers postgres sets ]
This whole thing is a massive over-reaction to a problem we almost certainly
know how to fix fairly simply and
Peter Geoghegan pe...@2ndquadrant.com writes:
On 5 August 2011 20:07, Tom Lane t...@sss.pgh.pa.us wrote:
If I were trying to get rid of this warning, I'd be wondering why
ReplNodeTag is a distinct enum in the first place.
Indeed, that doesn't seem to be justified anywhere, and seems to be a
Jeff Janes jeff.ja...@gmail.com writes:
My experiments have shown that the freelist proper is not
substantially faster than the freelist clocksweep--and that is even
under the assumption that putting things back into the freelist is
absolutely free.
The freelist isn't there to make buffer
Jeff Davis pg...@j-davis.com writes:
A control knob sounds limited. For instance, what if the application
knows that some parameters will be constant over the time that the plan
is saved? It would be nice to be able to bind some parameters to come up
with a generic (but less generic) plan, and
On Tue, Jul 26, 2011 at 12:18 PM, Timothy D. F. Lewis
elatl...@gmail.com wrote:
I'm not sure what David did for me so as per Roberts suggestion I have added
this patch to the commit fest.
I'm hoping I have not put this patch in more than one workflow.
Hi Tim,
I would be willing to review this
Hi Josh,
Thanks for help. Attached is a patch including changes suggested in your
comments.
Excerpts from Josh's message On Sat, Aug 6, 2011 at 9:57 PM:
1. It wasn't clear to me whether you're OK with Aron's suggested
tweak, please include it in your patch if so.
I decided to and included
27 matches
Mail list logo
