On Sun, Aug 7, 2011 at 12:41 AM, Tim wrote:
> 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
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 inclu
On Tue, Jul 26, 2011 at 12:18 PM, Timothy D. F. Lewis
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 patch for the n
Jeff Davis 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 then execute
Jeff Janes 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 allocation faster, t
Peter Geoghegan writes:
> On 5 August 2011 20:07, Tom Lane 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
> violation of the abstraction of N
On Fri, Aug 5, 2011 at 08:53, Andrew Dunstan 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 relatively pa
Tom Lane 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 plans.
Another wa
Robert Haas 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 ought to be very po
On Wed, Aug 3, 2011 at 3:21 PM, Jim Nasby 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 compl
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 11:21 AM, Robert Haas 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 test harness for d
Thomas Girault 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 0 shift/reduce
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 p
Jaime Casanova writes:
> On Sat, Aug 6, 2011 at 11:05 AM, Heikki Linnakangas
> 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,
>> and skip WAL after that. Of course, loading 10001 r
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
On Sat, Aug 6, 2011 at 11:05 AM, 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, s
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
Dean Rasheed 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 think a large
part of t
On 5 August 2011 20:07, Tom Lane 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 code was perfect
On 6 August 2011 11:03, Peter Eisentraut wrote:
> On lör, 2011-08-06 at 08:04 +0100, Dean Rasheed wrote:
>> On 4 August 2011 18:57, Peter Eisentraut wrote:
>> > Have you considered just cataloging NOT NULL constraints as CHECK
>> > constraints and teaching the reverse parser to convert "x CHECK (
On Sat, Aug 6, 2011 at 4:16 AM, 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.
Below a certain poin
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 cu
On lör, 2011-08-06 at 08:04 +0100, Dean Rasheed wrote:
> On 4 August 2011 18:57, Peter Eisentraut 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 t
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 W
On 6 August 2011 08:17, 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.
>
Oops, that should have been "depending on whether the PK is def
On 6 August 2011 01:01, Peter Eisentraut 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 exactly alike
On 4 August 2011 18:57, Peter Eisentraut 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 essential
28 matches
Mail list logo
