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
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,
that
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
Fabien COELHO coe...@cri.ensmp.fr 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
On Fri, May 20, 2011 at 2:35 PM, Gurjeet Singh singh.gurj...@gmail.com wrote:
On Sat, May 14, 2011 at 5:03 PM, Josh Kupershmidt schmi...@gmail.com
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
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
2011/5/5 Hitoshi Harada umi.tan...@gmail.com:
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
On 27.04.2011 04:19, Heikki Linnakangas wrote:
On 26.04.2011 21:30, Tom Lane wrote:
Heikki Linnakangasheikki.linnakan...@enterprisedb.com 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
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
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
On Sat, May 21, 2011 at 4:09 PM, Kevin Grittner kevin.gritt...@wicourts.gov
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
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;
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 extended
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
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
On Sat, May 21, 2011 at 12:13 PM, Alvaro Herrera
alvhe...@commandprompt.com 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
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 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 composite
On Sat, May 21, 2011 at 7:51 PM, Robert Haas robertmh...@gmail.com 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
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 4:09 PM, Kevin Grittner
kevin.gritt...@wicourts.gov 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
On Sat, May 21, 2011 at 8:36 PM, Kevin Grittner
kevin.gritt...@wicourts.gov 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
On Sat, May 21, 2011 at 5:47 PM, Peter Eisentraut pete...@gmx.net 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
On Sat, May 21, 2011 at 5:31 PM, Robert Haas robertmh...@gmail.com wrote:
On Sat, May 21, 2011 at 7:51 PM, Robert Haas robertmh...@gmail.com wrote:
Another point is that parsing overhead is quite obviously not the
reason for the massive performance gap between one core running simple
selects
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 8:41 PM, Jeff Janes jeff.ja...@gmail.com wrote:
On Sat, May 21, 2011 at 5:31 PM, Robert Haas robertmh...@gmail.com wrote:
On Sat, May 21, 2011 at 7:51 PM, Robert Haas robertmh...@gmail.com wrote:
Another point is that parsing overhead is quite obviously not the
reason
On Sat, May 21, 2011 at 8:50 PM, Kevin Grittner
kevin.gritt...@wicourts.gov 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.
2011/5/21 Peter Eisentraut pete...@gmx.net:
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
2011/5/21 Alvaro Herrera alvhe...@commandprompt.com:
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
29 matches
Mail list logo
