Excerpts from Bruce Momjian's message of mar ago 02 22:46:55 -0400 2011:
> I have created a documentation patch to clarify this, and to mention
> CREATE TABLE AS which also has this optimization.
It doesn't seem particularly better to me. How about something like
In minimal level, WAL-logging o
Excerpts from Dean Rasheed's message of sáb jul 30 18:40:46 -0400 2011:
> Looks pretty good to me (not too dirty). I suppose given that the
> parser transforms AT_ColumnConstraint into one of the existing command
> subtypes, you could just have gram.y emit an AT_AddConstraint with the
> ColumnDef
On Tue, Aug 2, 2011 at 9:47 PM, Tom Lane wrote:
> The most straightforward way to reimplement things within spi.c would be
> to redefine SPI_prepare as just doing the parse-and-rewrite steps, with
> planning always postponed to SPI_execute. In the case where you just
> prepare and then execute a
On Tue, Aug 2, 2011 at 2:32 PM, Kevin Grittner
wrote:
>>> Would you feel comfortable with a patch which threw an error on
>>> the DELETE case, as it does on the UPDATE case?
>>
>> Yes, though with a little additional twist. The twist being that
>> I'd like the error to be thrown earlier, at the ti
Robert Haas wrote:
> On Tue, Aug 2, 2011 at 11:30 AM, Bruce Momjian wrote:
> > Tom Lane wrote:
> >> Bruce Momjian writes:
> >> > Our docs suggest an optimization to reduce WAL logging when you are
> >> > creating and populating a table:
> >>
> >> > ? ?
> >> > http://www.postgresql.org/docs/9.0/s
On Tue, Aug 2, 2011 at 4:47 PM, Tom Lane wrote:
> I've been thinking about how to redesign the plancache infrastructure to
> better support use of transient (one-shot) plans, as we've talked about
> various times such as in this thread:
> http://archives.postgresql.org/pgsql-hackers/2010-02/msg006
On Tue, Aug 2, 2011 at 11:30 AM, Bruce Momjian wrote:
> Tom Lane wrote:
>> Bruce Momjian writes:
>> > Our docs suggest an optimization to reduce WAL logging when you are
>> > creating and populating a table:
>>
>> >
>> > http://www.postgresql.org/docs/9.0/static/runtime-config-wal.html#RUNTI
On Tue, Aug 2, 2011 at 8:44 PM, Tom Lane wrote:
> Robert Haas writes:
>>> If you want erand48_r, best to provide that API, not kluge up some
>>> other functions.
>
>> ...because erand48() is a GNU extension with a stupid API.
>
> I assume you mean erand48_r, there, because erand48 is pretty stand
Robert Haas writes:
>> If you want erand48_r, best to provide that API, not kluge up some
>> other functions.
> ...because erand48() is a GNU extension with a stupid API.
I assume you mean erand48_r, there, because erand48 is pretty standard.
> I don't
> see much value in supporting that, on bo
I'm happy to report that thanks to some persistent complaining on my
part, the one outstanding issue when building Postgres with Clang -
the spurious warnings that occured as a result of it being statically
detected that there are assignments past what appears to be the end of
a single element arra
Phil Sorber writes:
> I have included two patches in this email. The first
> (dump_user_config_last_with_set_role.patch) is an extension of my
> first patch. In addition to moving the ALTER ROLE statements after the
> CREATE ROLE statements it also inserts a SET ROLE after every connect.
> It take
Tom Lane wrote:
> The most straightforward way to reimplement things within spi.c
> would be to redefine SPI_prepare as just doing the
> parse-and-rewrite steps, with planning always postponed to
> SPI_execute. In the case where you just prepare and then execute
> a SPIPlan, this would come out
I've been thinking about how to redesign the plancache infrastructure to
better support use of transient (one-shot) plans, as we've talked about
various times such as in this thread:
http://archives.postgresql.org/pgsql-hackers/2010-02/msg00607.php
(Note: that thread sorta went off into the weeds a
"Kevin Grittner" wrote:
> Florian Pflug wrote:
>> Hm, OK I see your point now I believe. This is not so much about
>> wanting to put things into BEFORe triggers which doesn't really
>> fit there, but instead avoiding weeks of debugging if someones
>> messes up.
>
> I would say that is the ove
Florian Pflug wrote:
> On Aug2, 2011, at 17:03 , Kevin Grittner wrote:
> Hm, OK I see your point now I believe. This is not so much about
> wanting to put things into BEFORe triggers which doesn't really
> fit there, but instead avoiding weeks of debugging if someones
> messes up.
I would say
2011/8/2 Robert Haas :
> On Mon, Aug 1, 2011 at 4:27 PM, Alvaro Herrera
> wrote:
>> Excerpts from Robert Haas's message of lun ago 01 16:12:56 -0400 2011:
>>> On Mon, Aug 1, 2011 at 4:02 PM, Alvaro Herrera
>>> wrote:
>>> > Excerpts from Kohei KaiGai's message of dom jul 31 02:21:55 -0400 2011:
>>
On Aug2, 2011, at 17:03 , Kevin Grittner wrote:
> Florian Pflug wrote:
>> First, I'm not sure this is even a bug. To me, it seems that
>> postgres currently resolves an inherently ambiguous situation in
>> one possible way, while you expect it to pick another. It might be
>> that the behaviour tha
I have included two patches in this email. The first
(dump_user_config_last_with_set_role.patch) is an extension of my
first patch. In addition to moving the ALTER ROLE statements after the
CREATE ROLE statements it also inserts a SET ROLE after every connect.
It takes the role parameter from the -
On 02.08.2011 20:06, Alvaro Herrera wrote:
Excerpts from Heikki Linnakangas's message of mar ago 02 11:59:24 -0400 2011:
On 02.08.2011 15:18, Simon Riggs wrote:
On Tue, Aug 2, 2011 at 12:43 PM, Heikki Linnakangas
wrote:
On 02.08.2011 14:36, Simon Riggs wrote:
Actually I think we can append
On 02.08.2011 15:18, Simon Riggs wrote:
On Tue, Aug 2, 2011 at 12:43 PM, Heikki Linnakangas
wrote:
On 02.08.2011 14:36, Simon Riggs wrote:
Actually I think we can append the new information to the end of the page
split record, so that an old version server can read WAL generated by new
version
Bruce Momjian writes:
>>> In minimal level, WAL-logging of some bulk operations, like CREATE
>>> INDEX, CLUSTER and COPY on a table that was created or truncated in the
>>> same transaction can be safely skipped, which can make those operations
>>> much faster (see Section 14.4.7).
> But the docu
Merlin Moncure wrote:
> On Tue, Aug 2, 2011 at 8:34 AM, Bruce Momjian wrote:
> > Our docs suggest an optimization to reduce WAL logging when you are
> > creating and populating a table:
> >
> > ? ? ?
> > ?http://www.postgresql.org/docs/9.0/static/runtime-config-wal.html#RUNTIME-CONFIG-WAL-SETTING
Tom Lane wrote:
> Bruce Momjian writes:
> > Our docs suggest an optimization to reduce WAL logging when you are
> > creating and populating a table:
>
> >
> > http://www.postgresql.org/docs/9.0/static/runtime-config-wal.html#RUNTIME-CONFIG-WAL-SETTINGS
>
> > In minimal level, WAL-
Current thought among the core committee is to put out 9.1RC1 on Aug 22
(hence, wrap on the 18th), and then push forward to official release
mid-September (possibly the 12th, if nothing major pops up).
Personally I'd have preferred another beta or RC sooner than the 22nd,
but enough people are on
Florian Pflug wrote:
> On Aug1, 2011, at 20:02 , Kevin Grittner wrote:
>> I consider the trigger behavior addressed by this patch to be a
>> bug, and serious enough to merit inclusion of a fix in the 9.1
>> release, even at this late stage.
>
> I'm sorry but I disagree, on multiple grounds.
T
Bruce Momjian writes:
> Our docs suggest an optimization to reduce WAL logging when you are
> creating and populating a table:
>
> http://www.postgresql.org/docs/9.0/static/runtime-config-wal.html#RUNTIME-CONFIG-WAL-SETTINGS
> In minimal level, WAL-logging of some bulk opera
On 02.08.2011 16:34, Bruce Momjian wrote:
Our docs suggest an optimization to reduce WAL logging when you are
creating and populating a table:
http://www.postgresql.org/docs/9.0/static/runtime-config-wal.html#RUNTIME-CONFIG-WAL-SETTINGS
In minimal level, WAL-logging of
On Tue, Aug 2, 2011 at 8:34 AM, Bruce Momjian wrote:
> Our docs suggest an optimization to reduce WAL logging when you are
> creating and populating a table:
>
>
> http://www.postgresql.org/docs/9.0/static/runtime-config-wal.html#RUNTIME-CONFIG-WAL-SETTINGS
>
> In minimal level, WAL
Our docs suggest an optimization to reduce WAL logging when you are
creating and populating a table:
http://www.postgresql.org/docs/9.0/static/runtime-config-wal.html#RUNTIME-CONFIG-WAL-SETTINGS
In minimal level, WAL-logging of some bulk operations, like CREATE
IN
Am 01.08.2011 um 21:37 schrieb Merlin Moncure:
> I think David is probably right and this can be handled in pure sql
> simply and easily (perhaps in a function, perhaps not). The SPI
> interface is great, but the sql and plpgsql languages are very
> powerful and should always be preferred over a
Hi!
I'm now working on adding features to your version of patch. Current version
is attached. Somehow this version produce huge amount of WAL and that makes
it slow. Though count and avg. length of WAL records is similar to that of
non-buffering build.
test=# create table points as (select point(
On Tue, Aug 2, 2011 at 12:43 PM, Heikki Linnakangas
wrote:
> On 02.08.2011 14:36, Simon Riggs wrote:
>>
>> On Tue, Aug 2, 2011 at 12:03 PM, Heikki Linnakangas
>> wrote:
>>>
>>> If we change the WAL record, we have to make it so that the new version
>>> can
>>> still read the old format, which co
On Tue, Aug 2, 2011 at 12:28 PM, Dean Rasheed wrote:
> On 1 August 2011 21:02, Simon Riggs wrote:
>> I would prefer an approach where we store the events in a buffer,
>> which gets added to the main event queue when it fills/block number
>> changes/etc. That way we can apply intelligence to the a
On 02.08.2011 14:36, Simon Riggs wrote:
On Tue, Aug 2, 2011 at 12:03 PM, Heikki Linnakangas
wrote:
If we change the WAL record, we have to make it so that the new version can
still read the old format, which complicates the implementation a bit.
Neverthelss, I'm leaning towards option 1.
We
On Tue, Aug 2, 2011 at 12:03 PM, Heikki Linnakangas
wrote:
> On 01.08.2011 13:44, Heikki Linnakangas wrote:
>>
>> On 01.08.2011 13:13, Simon Riggs wrote:
>>>
>>> Did you want me to write the patch for 9.0?
>>
>> I'm looking at it now.
>
> So, in 9.0, we currently leave the rightlink and NSN invali
On 1 August 2011 21:02, Simon Riggs wrote:
> I would prefer an approach where we store the events in a buffer,
> which gets added to the main event queue when it fills/block number
> changes/etc. That way we can apply intelligence to the actual
> compression format used, yet retain all required in
On 01.08.2011 13:44, Heikki Linnakangas wrote:
On 01.08.2011 13:13, Simon Riggs wrote:
Did you want me to write the patch for 9.0?
I'm looking at it now.
So, in 9.0, we currently leave the rightlink and NSN invalid when
replaying a page split. To set them correctly, we'd need the old
right
On Tue, Aug 2, 2011 at 3:45 PM, Heikki Linnakangas <
heikki.linnakan...@enterprisedb.com> wrote:
> On 02.08.2011 12:54, Ashutosh Bapat wrote:
>
>> Hi All,
>> I am looking at usage of bound parameters.
>>
>> In functions SPI_cursor_open_with_args() and SPI_cursor_open_with_args()
>> parameters are
On 02.08.2011 12:54, Ashutosh Bapat wrote:
Hi All,
I am looking at usage of bound parameters.
In functions SPI_cursor_open_with_args() and SPI_cursor_open_with_args()
parameters are flagged as constants and passed to the planner in following
manner,
paramLI = _SPI_convert_params(nargs, argtypes,
Hi All,
I am looking at usage of bound parameters.
In functions SPI_cursor_open_with_args() and SPI_cursor_open_with_args()
parameters are flagged as constants and passed to the planner in following
manner,
paramLI = _SPI_convert_params(nargs, argtypes,
Values, N
On Aug1, 2011, at 20:02 , Kevin Grittner wrote:
> "Kevin Grittner" wrote:
> I consider the trigger behavior addressed by this patch to be a bug,
> and serious enough to merit inclusion of a fix in the 9.1 release,
> even at this late stage.
I'm sorry but I disagree, on multiple grounds.
First, I
On 1 August 2011 20:53, Tom Lane wrote:
> Dean Rasheed writes:
>> OK, so I should split this into 2 patches?
>> Even without the compression, it's probably worth the 16 -> 10 byte
>> reduction that would result from removing the 2nd CTID in the UPDATE
>> case, and that part would be a pretty smal
42 matches
Mail list logo
