2011/5/21 Alvaro Herrera :
> Excerpts from Pavel Stehule's message of sáb may 21 16:05:01 -0400 2011:
>
>> A implementation of ERROR_CONTEXT is not without impact on
>> performance, because context should be collected when exception is
>> caught. One solution is removing a ERROR_CONTEXT from propos
2011/5/21 Peter Eisentraut :
> I noticed the 9.1 release notes claim that the new
> EDITOR_LINENUMBER_SWITCH thing is an environment variable, whereas it is
> actually a psql variable.
>
> This is perhaps sort of a Freudian slip. Since the editor itself is
> configured using an environment variabl
On Sat, May 21, 2011 at 8:50 PM, Kevin Grittner
wrote:
> Robert Haas wrote:
>> How is an UPDATE different from a DELETE and an INSERT?
>
> That's the question Jeff asked which caused us to revisit this.
>
> There are two answers -- conceptual and implementation.
>
> Conceptually, an updated row i
On Sat, May 21, 2011 at 8:41 PM, Jeff Janes wrote:
> On Sat, May 21, 2011 at 5:31 PM, Robert Haas wrote:
>> On Sat, May 21, 2011 at 7:51 PM, Robert Haas wrote:
>>> Another point is that parsing overhead is quite obviously not the
>>> reason for the massive performance gap between one core runnin
Robert Haas wrote:
> How is an UPDATE different from a DELETE and an INSERT?
That's the question Jeff asked which caused us to revisit this.
There are two answers -- conceptual and implementation.
Conceptually, an updated row is the same row, and a row inserted after a
delete is a new row.
On Sat, May 21, 2011 at 5:31 PM, Robert Haas wrote:
> On Sat, May 21, 2011 at 7:51 PM, Robert Haas wrote:
>> Another point is that parsing overhead is quite obviously not the
>> reason for the massive performance gap between one core running simple
>> selects on PostgreSQL and one core running si
On Sat, May 21, 2011 at 5:47 PM, Peter Eisentraut wrote:
> I noticed the 9.1 release notes claim that the new
> EDITOR_LINENUMBER_SWITCH thing is an environment variable, whereas it is
> actually a psql variable.
>
> This is perhaps sort of a Freudian slip. Since the editor itself is
> configured
On Sat, May 21, 2011 at 8:36 PM, Kevin Grittner
wrote:
> Robert Haas wrote:
>> Incidentally, prepared transactions help a lot.
>
> Prepared transactions or prepared statements?
Uh, statements. -M prepared.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Comp
On Sat, May 21, 2011 at 4:09 PM, Kevin Grittner
wrote:
> [Anyone who has followed along this far has earned my undying
> gratitude.]
>
> Since the chain of transactions has to overlap T0 and T3, I don't see
> how that can happen. We established that T0 has to commit before T3 can
> start, so the
Robert Haas wrote:
> Incidentally, prepared transactions help a lot.
Prepared transactions or prepared statements?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sat, May 21, 2011 at 7:51 PM, Robert Haas wrote:
> Another point is that parsing overhead is quite obviously not the
> reason for the massive performance gap between one core running simple
> selects on PostgreSQL and one core running simple selects on MySQL.
> Even if I had (further) eviscerat
On Sat, May 21, 2011 at 08:25:30AM -0400, Heikki Linnakangas wrote:
> On 28.04.2011 15:41, Noah Misch wrote:
>> Now that we have ALTER TYPE DROP ATTRIBUTE, pg_dump --binary-upgrade must,
>> for
>> the sake of composite-typed columns, preserve the dropped-column
>> configuration
>> of stand-alone
On Sat, May 21, 2011 at 04:45:15PM -0400, Pavan Deolasee wrote:
> As a first step, it would be great if you can upload the slides on the
> conference website. To expect that the attendees would have understood the
> nitty-gritties of SSI just listening to the presentation is so unhuman :-)
I just
On Sat, May 21, 2011 at 12:13 PM, Alvaro Herrera
wrote:
> Excerpts from Robert Haas's message of vie may 20 18:41:37 -0400 2011:
>> This means that, in a situation where aren't using DML, and are
>> running very simple queries without prepared statements, the parser
>> bloat resulting from support
Excerpts from Pavel Stehule's message of sáb may 21 16:05:01 -0400 2011:
> A implementation of ERROR_CONTEXT is not without impact on
> performance, because context should be collected when exception is
> caught. One solution is removing a ERROR_CONTEXT from proposal. Second
> solution can be a de
I noticed the 9.1 release notes claim that the new
EDITOR_LINENUMBER_SWITCH thing is an environment variable, whereas it is
actually a psql variable.
This is perhaps sort of a Freudian slip. Since the editor itself is
configured using an environment variable, shouldn't any configuration
about the
Hello Tom,
Add "AS EXPLICIT" to "CREATE CAST" This gives a name to the default
case of "CREATE CAST", which creates a cast which must be explicitely
invoked.
I'm not sure this is a good idea. The CREATE CAST syntax is in the SQL
standard, and this isn't it. Now I realize that we've extende
Pavan Deolasee wrote:
> As a first step, it would be great if you can upload the slides on
> the conference website. To expect that the attendees would have
> understood the nitty-gritties of SSI just listening to the
> presentation is so unhuman :-)
I'm sure Dan will be doing that soon; meanw
On Sat, May 21, 2011 at 4:09 PM, Kevin Grittner wrote:
>
> It would be great if anyone with a grasp
> of SSI concepts could confirm its validity or shoot it down. (Hopefully
> Friday's presentation expanded the number of those who can do so.)
>
>
As a first step, it would be great if you can upl
As background, for most of SSI development I had a TODO comment in the
source which was basically around the question of whether a predicate
lock on a visible heap tuple should propagate to later versions of the
row as long as the original lock was material. In early February Heikki
(quite reasona
Hello
This proposal is related to exception processing. Inside exception
handler we can get some basic info about exception - message text and
message code. There are other fields - but these fields are no
available now in PL/pgSQL. The cheap access to fields inside ErrorData
structure can be impl
On 27.04.2011 04:19, Heikki Linnakangas wrote:
On 26.04.2011 21:30, Tom Lane wrote:
Heikki Linnakangas writes:
The trivial fix is to reset the per-tuple memory context between
iterations.
Have you tested this with SRFs?
ForeignNext seems like quite the wrong place for resetting
exprcontext i
2011/5/5 Hitoshi Harada :
> https://commitfest.postgresql.org/action/patch_view?id=548
>
> I'll work further if I find time.
After more thought, pulling up aggregate subquery in narrow
conditional cases is quite hard path, especially when the joinrel is
more than 2. It will be hard to check pullin
Excerpts from Robert Haas's message of vie may 20 18:41:37 -0400 2011:
> This means that, in a situation where aren't using DML, and are
> running very simple queries without prepared statements, the parser
> bloat resulting from supporting all the other kinds of queries which
> aren't being exerc
On Fri, May 20, 2011 at 2:35 PM, Gurjeet Singh wrote:
> On Sat, May 14, 2011 at 5:03 PM, Josh Kupershmidt
> wrote:
> Thanks a lot for the review. My responses are inline below.
Thanks for the fixes. Your updated patch is sent as a
patch-upon-a-patch, it'll probably be easier for everyone
(partic
Fabien COELHO writes:
> Description:
> Add "AS EXPLICIT" to "CREATE CAST"
> This gives a name to the default case of "CREATE CAST", which creates a
> cast which must be explicitely invoked.
I'm not sure this is a good idea. The CREATE CAST syntax is in the SQL
standard, and this isn't it. Now
Hello,
Please find attached a minor stylish patch. It compiles and the update
test cases work for me.
Description:
Add "AS EXPLICIT" to "CREATE CAST"
This gives a name to the default case of "CREATE CAST", which creates a
cast which must be explicitely invoked.
From a language definition
>There's some potentially useful information here:
>http://www.postgresql.org/docs/9.0/interactive/textsearch-controls.html#TEXTSEARCH-RANKING
Thanks for reply. I was reading the documentation of PostgreSQL, but there
it is not written the name of the used methods. Everywhere there is written,
tha
On 28.04.2011 15:41, Noah Misch wrote:
Now that we have ALTER TYPE DROP ATTRIBUTE, pg_dump --binary-upgrade must, for
the sake of composite-typed columns, preserve the dropped-column configuration
of stand-alone composite types. Here's a test case:
create type t as (x int, y int);
create table
29 matches
Mail list logo
