On 1 August 2011 20:53, Tom Lane t...@sss.pgh.pa.us wrote:
Dean Rasheed dean.a.rash...@gmail.com 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
On Aug1, 2011, at 20:02 , Kevin Grittner wrote:
Kevin Grittner kevin.gritt...@wicourts.gov 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
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,
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,
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 flagged as
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
On 1 August 2011 21:02, Simon Riggs si...@2ndquadrant.com 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
On Tue, Aug 2, 2011 at 12:03 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
On 02.08.2011 14:36, Simon Riggs wrote:
On Tue, Aug 2, 2011 at 12:03 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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,
On Tue, Aug 2, 2011 at 12:28 PM, Dean Rasheed dean.a.rash...@gmail.com wrote:
On 1 August 2011 21:02, Simon Riggs si...@2ndquadrant.com 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
On Tue, Aug 2, 2011 at 12:43 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 02.08.2011 14:36, Simon Riggs wrote:
On Tue, Aug 2, 2011 at 12:03 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
If we change the WAL record, we have to make it so that the
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
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 C
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
On Tue, Aug 2, 2011 at 8:34 AM, Bruce Momjian br...@momjian.us 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
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
Bruce Momjian br...@momjian.us 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
Florian Pflug f...@phlo.org 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
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
Tom Lane wrote:
Bruce Momjian br...@momjian.us 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,
Merlin Moncure wrote:
On Tue, Aug 2, 2011 at 8:34 AM, Bruce Momjian br...@momjian.us wrote:
Our docs suggest an optimization to reduce WAL logging when you are
creating and populating a table:
? ? ?
Bruce Momjian br...@momjian.us 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
On 02.08.2011 15:18, Simon Riggs wrote:
On Tue, Aug 2, 2011 at 12:43 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
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
heikki.linnakan...@enterprisedb.com wrote:
On 02.08.2011 14:36, Simon Riggs
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 Aug2, 2011, at 17:03 , Kevin Grittner wrote:
Florian Pflug f...@phlo.org 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
2011/8/2 Robert Haas robertmh...@gmail.com:
On Mon, Aug 1, 2011 at 4:27 PM, Alvaro Herrera
alvhe...@commandprompt.com 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
alvhe...@commandprompt.com wrote:
Excerpts from
Florian Pflug f...@phlo.org 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
Kevin Grittner kevin.gritt...@wicourts.gov wrote:
Florian Pflug f...@phlo.org 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'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
Tom Lane t...@sss.pgh.pa.us 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
Phil Sorber p...@omniti.com 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
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
Robert Haas robertmh...@gmail.com 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
On Tue, Aug 2, 2011 at 8:44 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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,
On Tue, Aug 2, 2011 at 11:30 AM, Bruce Momjian br...@momjian.us wrote:
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Our docs suggest an optimization to reduce WAL logging when you are
creating and populating a table:
On Tue, Aug 2, 2011 at 4:47 PM, Tom Lane t...@sss.pgh.pa.us 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:
Robert Haas wrote:
On Tue, Aug 2, 2011 at 11:30 AM, Bruce Momjian br...@momjian.us wrote:
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Our docs suggest an optimization to reduce WAL logging when you are
creating and populating a table:
? ?
On Tue, Aug 2, 2011 at 2:32 PM, Kevin Grittner
kevin.gritt...@wicourts.gov 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
On Tue, Aug 2, 2011 at 9:47 PM, Tom Lane t...@sss.pgh.pa.us 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
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
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 of
42 matches
Mail list logo
