On Fri, Feb 10, 2012 at 10:38 PM, Jim Nasby j...@nasby.net wrote:
On 2/7/12 8:14 AM, Alvaro Herrera wrote:
Having one sequence for each toast table could be wasteful though. I
mean, sequences are not the best use of shared buffer cache currently.
If we could have more than one sequence data
On Fri, Feb 10, 2012 at 01:59:18PM -0500, Robert Haas wrote:
I guess I'm not particularly excited by the idea of trying to make
TRUNCATE MVCC-safe. I notice that the example involves the REPEATABLE
READ isolation level, which is already known to be busted in a variety
of ways; that's why we
On Thu, Feb 9, 2012 at 11:30, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Tom Lane's message of jue feb 09 12:17:59 -0300 2012:
FWIW that script is throwing a warning here:
Use of assignment to $[ is deprecated at
On 2012-02-09 22:17, Jesper Krogh wrote:
On 2012-02-09 21:09, Robert Haas wrote:
That doesn't make sense to me. If you probe index A for rows where a
= 1 and find that CTID (100,1) is such a row, and now want to return a
column value b that is not present in that index, the fastest way to
get
On 02/09/2012 03:06 PM, Andrew Dunstan wrote:
On 02/09/2012 02:54 PM, Tom Lane wrote:
Andrew Dunstanand...@dunslane.net writes:
OK, the one place that needs to be fixed to avoid the crash caused by
the json regression tests with the original patch is in
On 02/10/2012 01:14 PM, Peter Eisentraut wrote:
The auto_explain module appears to create invalid JSON (in all versions
since 9.0). For example, with the settings
auto_explain.log_format = 'json'
auto_explain.log_min_duration = 0
the query
select * from pg_type;
produces this in the log:
Kevin Grittner wrote:
Tom Lane wrote:
I agree it's a bug that you can do what Kevin's example shows.
I'll look at it and see if I can pull together a patch.
Attached.
Basically, if a GUC has a check function, this patch causes it to be
run on a RESET just like it is on a SET, to make
On Wed, Feb 8, 2012 at 1:01 AM, Hitoshi Harada umi.tan...@gmail.com wrote:
On Sun, Jan 15, 2012 at 4:59 PM, Jeff Janes jeff.ja...@gmail.com wrote:
The attached patch allows it to reuse that memory. On my meager
system it reduced the building of an index on an integer column in a
skinny 200
I wrote:
BTW, it occurs to me to wonder whether we need to worry about such
subsidiary leaks in type input functions as well.
Sure enough, once you find an input function that leaks memory, there's
trouble:
create type myrow as (f1 text, f2 text, f3 text);
create or replace function
On 02/11/2012 01:18 PM, Andrew Dunstan wrote:
On 02/10/2012 01:14 PM, Peter Eisentraut wrote:
[ auto-explain JSON output should be an object instead of an array ]
Yeah, looks like this dates back to when we first got JSON output.
Auto-explain does this:
ExplainBeginOutput(es);
Andrew Dunstan and...@dunslane.net writes:
But ExplainBeginOutput says:
case EXPLAIN_FORMAT_JSON:
/* top-level structure is an array of plans */
appendStringInfoChar(es-str, '[');
Now that's not true in the auto-explain case, which prints one query +
one plan.
On 02/11/2012 03:22 PM, Tom Lane wrote:
Andrew Dunstanand...@dunslane.net writes:
But ExplainBeginOutput says:
case EXPLAIN_FORMAT_JSON:
/* top-level structure is an array of plans */
appendStringInfoChar(es-str, '[');
Now that's not true in the auto-explain
On 02/11/2012 03:22 PM, Tom Lane wrote:
Andrew Dunstanand...@dunslane.net writes:
But ExplainBeginOutput says:
case EXPLAIN_FORMAT_JSON:
/* top-level structure is an array of plans */
appendStringInfoChar(es-str, '[');
Now that's not true in the auto-explain
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= wulc...@wulczer.org writes:
This is annoying for functions that plough through large tables, doing
some calculation. Attached is a patch that does the conversion of
PostgreSQL Datums into Python dict objects in a scratch memory context
that gets reset every
On Tue, Feb 7, 2012 at 2:06 PM, Greg Smith g...@2ndquadrant.com wrote:
On 02/07/2012 03:23 PM, Bruce Momjian wrote:
Where did you see that there will be an improvement in the 9.2
documentation? I don't see an improvement.
I commented that I'm hoping for an improvement in the documentation
On Tue, Feb 7, 2012 at 4:58 PM, Bruce Momjian br...@momjian.us wrote:
I was initially concerned that tuning advice in this part of the docs
would look out of place, but now see the 25% shared_buffers
recommentation, and it looks fine, so we are OK. (Should we caution
against more than 8GB of
On Mon, Feb 6, 2012 at 6:38 AM, Robert Haas robertmh...@gmail.com wrote:
On Sat, Feb 4, 2012 at 2:13 PM, Jeff Janes jeff.ja...@gmail.com wrote:
We really need to nail that down. Could you post the scripts (on the
wiki) you use for running the benchmark and making the graph? I'd
like to see
On 19/09/2011 21:41, PostgreSQL - Hans-Jürgen Schönig wrote:
On Sep 19, 2011, at 5:16 PM, Tom Lane wrote:
Greg Starkst...@mit.edu writes:
That said, to help in the case I described you would have to implement
the tapesort algorithm on the GPU as well.
I think the real problem would be
On 19/09/2011 16:36, Greg Smith wrote:
On 09/19/2011 10:12 AM, Greg Stark wrote:
With the GPU I'm curious to see how well
it handles multiple processes contending for resources, it might be a
flashy feature that gets lots of attention but might not really be
very useful in practice. But it
I decided to take a crack at the todo item created from the following post:
http://archives.postgresql.org/pgsql-performance/2005-10/msg00458.php
The attached patch makes the desired changes in both code and function
naming.
It seemed quite easy to do but wasn't marked as easy on the todo, so
20 matches
Mail list logo
