Having statistics on ranges was really missing! The planner was doing
some really, really bad choices on bigger tables regarding seq/random
scans, nested loop/other joins etc.
Is there any chance this makes it into 9.2 final? It would really
round-off the introduction of range types and maybe avoi
Hi, hackersI was exporting my project to a patch file. As the patch review
requires, the patch needs to be in context diff format
(http://wiki.postgresql.org/wiki/Reviewing_a_Patch). But the git diff exports
in a format similar to unified format. What is everyone doing with patching
now? Is
2012/8/7 Peter Geoghegan :
> On 7 August 2012 20:01, Andrew Dunstan wrote:
>> On 08/07/2012 02:14 PM, Tom Lane wrote:
>>> * As per some of the complaints already registered in this thread,
>>> ruleutils.c is not designed with the goal of being a pretty-printer.
>>> Its primary charter is to suppor
2012/8/7 Tom Lane :
> Andrew Dunstan writes:
>> On 08/07/2012 02:14 PM, Tom Lane wrote:
>>> In short, the only redeeming value of this patch is that it's short.
>
>> One of the challenges is to have a pretty printer that is kept in sync
>> with the dialect that's supported. Anything that doesn't u
On Tue, Aug 7, 2012 at 1:52 PM, Simon Riggs wrote:
> On 7 August 2012 20:58, Jeff Janes wrote:
>> Hi Heikki,
>>
>> Is the bulk index insert still an active area for you?
>>
>> If not, is there some kind of summary of design or analysis work
>> already done, which would be a useful for someone els
I have looked at the Postgres 9.2 stable and Postgres 9.2 beta 3 git
archives and this bug still appears to be present.
TwoPhaseGetDummyProc returns a PGPROC*. In 9.0, it was safe for
TwoPhaseGetDummyBackendId() to cast this to a GlobalTransaction
because the GlobalTransactionData structure
Did we ever decide on this? Is it a TODO?
---
On Fri, Jul 22, 2011 at 04:01:20PM -0500, Kevin Grittner wrote:
> Robert Haas wrote:
> > On Wed, Jul 20, 2011 at 2:58 PM, Kevin Grittner
> > wrote:
> >> So basically, the goal
I wrote:
> What I'd like to do next, barring objections, is to band-aid the places
> where the planner could crash on a LATERAL query (probably just make it
> throw FEATURE_NOT_SUPPORTED errors), write some documentation, and
> then commit what I've got. After that I can go back to improve the
> p
Peter Geoghegan writes:
> On 7 August 2012 20:01, Andrew Dunstan wrote:
>> One of the challenges is to have a pretty printer that is kept in sync with
>> the dialect that's supported. Anything that doesn't use the backend's parser
>> seems to me to be guaranteed to get out of sync very quickly.
On 7 August 2012 20:58, Jeff Janes wrote:
> On Fri, Aug 12, 2011 at 2:59 PM, Heikki Linnakangas
> wrote:
>> On 13.08.2011 00:17, Simon Riggs wrote:
>>>
>>> Also, we discussed that you would work on buffering the index inserts,
>>> which is where the main problem lies. The main heap is only a smal
On Tue, Aug 7, 2012 at 1:09 PM, Fujii Masao wrote:
> On Tue, Aug 7, 2012 at 10:22 PM, Magnus Hagander wrote:
>> Should we consider if we can make "pg_ctl -w" work for "promote" as well?
>
> +1
>
>> The main problem is, I guess, that it can't log in - so wed' need
>> something like "PQping()" that
On 7 August 2012 20:01, Andrew Dunstan wrote:
> On 08/07/2012 02:14 PM, Tom Lane wrote:
>> * As per some of the complaints already registered in this thread,
>> ruleutils.c is not designed with the goal of being a pretty-printer.
>> Its primary charter is to support pg_dump by regurgitating rules/
On Fri, Aug 12, 2011 at 2:59 PM, Heikki Linnakangas
wrote:
> On 13.08.2011 00:17, Simon Riggs wrote:
>>
>> Also, we discussed that you would work on buffering the index inserts,
>> which is where the main problem lies. The main heap is only a small
>> part of the overhead if we have multiple index
Andrew Dunstan writes:
> On 08/07/2012 02:14 PM, Tom Lane wrote:
>> In short, the only redeeming value of this patch is that it's short.
> One of the challenges is to have a pretty printer that is kept in sync
> with the dialect that's supported. Anything that doesn't use the
> backend's parser
On 08/07/2012 02:14 PM, Tom Lane wrote:
* As per some of the complaints already registered in this thread,
ruleutils.c is not designed with the goal of being a pretty-printer.
Its primary charter is to support pg_dump by regurgitating rules/views
in an unambiguous form, which does not necessari
Hi,
When I used pg_trgm, I encountered the problem that the search result of
SeqScan was the different from that of BitmapScan even if the search
keyword was the same. Is this a bug? Here is the test case:
---
CREATE EXTENSION pg_trgm;
CREATE TABLE tbl (col text);
CREATE I
Bruce Momjian writes:
> On Tue, Aug 7, 2012 at 04:14:34PM +0200, Pavel Stehule wrote:
>> last year we are spoke about reusing pretty print view code for some queries.
>>
>> Here is patch:
> I can see this as very useful for people reporting badly-formatted
> queries to our email lists. Great!
On 2 August 2012 17:18, Fujii Masao wrote:
> Hi,
>
> In HEAD and 9.2, the following scenario happens in archive recovery.
>
> 1. The archived WAL file is restored onto the temporary file name
> "RECOVERYXLOG".
> 2. The restored WAL file is renamed to the correct file name like
> 000100
Here's an updated version of my LATERAL patch.
* Accepts "LATERAL func_name(args)".
* Handles LATERAL in JOIN nests now. I rewrote the way
transformFromClause manages visibility of previously-parsed FROM items.
Rather than my previous idea of adding more namespace lists to a
ParseState, I change
On Wed, Jul 25, 2012 at 7:54 AM, Alexander Law wrote:
> Hello,
> I would like to fix this bug, but it looks like it would be not one-line
> patch.
> Looking at the pg_dump code I see that the object names come through the
> following chain:
> 1. pg_dump executes 'SELECT c.tableoid, c.oid, c.relnam
On Tue, Aug 07, 2012 at 03:59:42PM +0800, Craig Ringer wrote:
> On 08/07/2012 02:27 AM, Robert Haas wrote:
> >I did not commit the advanced.sgml changes.
>
> That's arguably the most important point to raise this. The most
> recent question came from someone who actually bothered to RTFM and
> bel
I just got a bug report from EnterpriseDB saying pg_upgrade generates a
file share violation on PG 9.2. I was initially confused because I know
we fixed this in a May commit. Well, it turns out that this commit
re-added the same failure:
commit 4741e9afb93f0d769655b2d18c2b73b86f281010
On Tue, Aug 7, 2012 at 10:22 PM, Magnus Hagander wrote:
> Should we consider if we can make "pg_ctl -w" work for "promote" as well?
+1
> The main problem is, I guess, that it can't log in - so wed' need
> something like "PQping()" that actually checked if it was master or
> slave?
Yes.
Regards
On Tue, Aug 07, 2012 at 04:54:12PM +0200, Pavel Stehule wrote:
> 2012/8/7 Thom Brown :
> > On 7 August 2012 15:14, Pavel Stehule wrote:
> >> Hello
> >>
> >> last year we are spoke about reusing pretty print view code for some
> >> queries.
> >>
> >> Here is patch:
> >>
> >> this patch is really s
On Tue, Aug 7, 2012 at 8:51 AM, Magnus Hagander wrote:
> Agreed. Anybody up for writing the text though? There was some text
> earlier (see
> http://git.postgresql.org/gitweb/?p=pgweb.git;a=commitdiff;h=bd02e36141bb99e9ee4e0b80fd69464e0e6d91b7#patch18
> or the corresponding one in the old pgweb r
On 08/07/2012 10:14 AM, Pavel Stehule wrote:
Hello
last year we are spoke about reusing pretty print view code for some queries.
Here is patch:
this patch is really short - it is nice. But - it works only with
known database objects (probably we would it) and it doesn't format
subqueries well
On Tue, Aug 7, 2012 at 04:14:34PM +0200, Pavel Stehule wrote:
> Hello
>
> last year we are spoke about reusing pretty print view code for some queries.
>
> Here is patch:
>
> this patch is really short - it is nice. But - it works only with
> known database objects (probably we would it) and it
On Tuesday, August 07, 2012 09:45:35 AM Kevin Grittner wrote:
[...snipped...]
> I also think it's a problem that one can get through the entire
> "Concurrency Control" chapter (mvcc.sgml) without a clue that
> sequences aren't transactional. I think maybe a mention in the
> Introduction section of
On Tue, Aug 7, 2012 at 10:38:52AM -0400, Alvaro Herrera wrote:
> Excerpts from Bruce Momjian's message of vie ago 03 16:02:28 -0400 2012:
> > On Fri, Aug 3, 2012 at 04:01:18PM -0400, Robert Haas wrote:
> > > On Fri, Aug 3, 2012 at 3:22 PM, Bruce Momjian wrote:
> > > >> I don't disagree with pg_u
2012/8/7 Thom Brown :
> On 7 August 2012 15:14, Pavel Stehule wrote:
>> Hello
>>
>> last year we are spoke about reusing pretty print view code for some queries.
>>
>> Here is patch:
>>
>> this patch is really short - it is nice. But - it works only with
>> known database objects (probably we woul
Excerpts from Bruce Momjian's message of vie ago 03 16:02:28 -0400 2012:
> On Fri, Aug 3, 2012 at 04:01:18PM -0400, Robert Haas wrote:
> > On Fri, Aug 3, 2012 at 3:22 PM, Bruce Momjian wrote:
> > >> I don't disagree with pg_upgrade being operationally complex, but I
> > >> don't see how this rela
On 7 August 2012 15:14, Pavel Stehule wrote:
> Hello
>
> last year we are spoke about reusing pretty print view code for some queries.
>
> Here is patch:
>
> this patch is really short - it is nice. But - it works only with
> known database objects (probably we would it) and it doesn't format
> su
Hello
last year we are spoke about reusing pretty print view code for some queries.
Here is patch:
this patch is really short - it is nice. But - it works only with
known database objects (probably we would it) and it doesn't format
subqueries well
postgres=# select pg_pretty_query('select x.*
On Tue, Aug 7, 2012 at 03:06:23PM +0200, Magnus Hagander wrote:
> On Fri, Aug 3, 2012 at 10:02 PM, Bruce Momjian wrote:
> > On Fri, Aug 3, 2012 at 04:01:18PM -0400, Robert Haas wrote:
> >> On Fri, Aug 3, 2012 at 3:22 PM, Bruce Momjian wrote:
> >> >> I don't disagree with pg_upgrade being operat
Robert Haas wrote:
> Craig Ringer wrote:
>> On 08/07/2012 02:27 AM, Robert Haas wrote:
>>>
>>> I did not commit the advanced.sgml changes.
>>
>> That's arguably the most important point to raise this. The most
>> recent question came from someone who actually bothered to RTFM
>> and believed base
Should we consider if we can make "pg_ctl -w" work for "promote" as well?
The main problem is, I guess, that it can't log in - so wed' need
something like "PQping()" that actually checked if it was master or
slave?
//Magnus
-- Forwarded message --
From: Manoj Govindassamy
Date:
On Fri, Aug 3, 2012 at 10:02 PM, Bruce Momjian wrote:
> On Fri, Aug 3, 2012 at 04:01:18PM -0400, Robert Haas wrote:
>> On Fri, Aug 3, 2012 at 3:22 PM, Bruce Momjian wrote:
>> >> I don't disagree with pg_upgrade being operationally complex, but I
>> >> don't see how this relates to contrib vs. no
On Tue, Aug 7, 2012 at 2:44 PM, Robert Haas wrote:
> On Mon, Aug 6, 2012 at 11:22 PM, Craig Ringer wrote:
>> Heya all
>>
>> It seems like it's a bit trickier to find beta downloads than might be
>> ideal.
>>
>> The beta info page simply reads:
>>
>> " PostgreSQL 9.2 beta 3 was released on Aug
On Mon, Aug 6, 2012 at 11:22 PM, Craig Ringer wrote:
> Heya all
>
> It seems like it's a bit trickier to find beta downloads than might be
> ideal.
>
> The beta info page simply reads:
>
> " PostgreSQL 9.2 beta 3 was released on August 6, 2012."
>
> with no information about how to obtain a bu
On Tue, Aug 7, 2012 at 2:02 AM, Etsuro Fujita
wrote:
>> I think that optimizations like this are going to be essential for
>> things like pgsql_fdw (or other_rdms_fdw). Despite the thorny
>> semantic issues, we're just not going to be able to get around it.
>> There will even be people who want S
On Tue, Aug 7, 2012 at 7:16 AM, Pavel Stehule wrote:
> Hello all
>
> I found strange behave of postgresql. I would to use name
> pg_stat_get_some for custom function. Probably it is not smart from
> me, because I found so functions that has prefix pg are not searched
> via search_path.
>
> postgre
On Tue, Aug 7, 2012 at 3:59 AM, Craig Ringer wrote:
> On 08/07/2012 02:27 AM, Robert Haas wrote:
>>
>> I did not commit the advanced.sgml changes.
>
> That's arguably the most important point to raise this. The most recent
> question came from someone who actually bothered to RTFM and believed bas
Hello all
I found strange behave of postgresql. I would to use name
pg_stat_get_some for custom function. Probably it is not smart from
me, because I found so functions that has prefix pg are not searched
via search_path.
postgres=# select public.pg_stat_get_creation_time('xxx'::regclass);
pg_
On 08/07/2012 02:27 AM, Robert Haas wrote:
I did not commit the advanced.sgml changes.
That's arguably the most important point to raise this. The most recent
question came from someone who actually bothered to RTFM and believed
based on the advanced-transactions page that rollback rolls *eve
44 matches
Mail list logo
