On Fri, Feb 10, 2012 at 10:38 PM, Jim Nasby 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 in a s
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 w
On Thu, Feb 9, 2012 at 11:30, Tom Lane wrote:
> Alvaro Herrera 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
>> /pgsql/source/HEAD/src/tools/check_keywords.pl line 19.
>
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 t
On 02/09/2012 03:06 PM, Andrew Dunstan wrote:
On 02/09/2012 02:54 PM, Tom Lane wrote:
Andrew Dunstan 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
src/backend/parser/parse_expr.c:transformRowExpr().
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 ma
On Wed, Feb 8, 2012 at 1:01 AM, Hitoshi Harada wrote:
> On Sun, Jan 15, 2012 at 4:59 PM, Jeff Janes 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 million row totally randomly orde
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 leak_ass
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 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.
What about q
On 02/11/2012 03:22 PM, Tom Lane wrote:
Andrew Dunstan 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 on
On 02/11/2012 03:22 PM, Tom Lane wrote:
Andrew Dunstan 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 on
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= 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 time.
As best I ca
On Tue, Feb 7, 2012 at 2:06 PM, Greg Smith 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 of how
> mu
On Tue, Feb 7, 2012 at 4:58 PM, Bruce Momjian 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 shared buffer
On Mon, Feb 6, 2012 at 6:38 AM, Robert Haas wrote:
> On Sat, Feb 4, 2012 at 2:13 PM, Jeff Janes 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 how much work it would be for me to
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 Stark 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 that we are seldo
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 would
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 I'm
20 matches
Mail list logo
