Hi All,
Consider following sequence of commands
create type complex as (r float8, i float8);
create type quad as (c1 complex, c2 complex);
create temp table quadtable(f1 int, q quad);
insert into quadtable (f1, q.c1.r, q.c2.i) values(44,55,66);
While parsing the INSERT query, we parse the query
On Wed, Mar 21, 2012 at 12:42 AM, Merlin Moncure wrote:
> On Tue, Mar 20, 2012 at 12:34 PM, Atri Sharma wrote:
>>
>>
>> -Original Message-
>> From: Merlin Moncure [mailto:mmonc...@gmail.com]
>> Sent: 20 March 2012 22:50
>> To: Atri Sharma
>> Cc: Heikki Linnakangas; Alvaro Herrera; Daniel
> Date: Tue, 20 Mar 2012 14:12:45 -0700> Subject: Re: [HACKERS] Gsoc2012 Idea
> --- Social Network database schema
> From: neil.con...@gmail.com
> To: huangq...@hotmail.com
> CC: dan...@heroku.com; j...@agliodbs.com; pgsql-hackers@postgresql.org
>
> 2012/3/19 Qi Huang :
> >> I actually tri
Marko Kreen writes:
> On Thu, Mar 15, 2012 at 11:29:31PM +0200, Alex wrote:
>> https://github.com/a1exsh/postgres/commits/uri
>
> The point of the patch is to have one string with all connection options,
> in standard format, yes? So why does not this work:
>
> db = PQconnectdb("postgres://lo
On Tue, Mar 20, 2012 at 8:00 PM, Robert Haas wrote:
>> Frankly that analysis didn't make any sense to me at the time.
>> Comparing integers is fast, sure, but it's still slower than not
>> having to do any comparison at all.
>
> I think you're underestimating how much it costs to call the
> dataty
Excerpts from Joachim Wieland's message of mar mar 20 08:26:52 -0300 2012:
> On Tue, Mar 20, 2012 at 12:03 AM, Erik Rijkers wrote:
> > In my hands, the patch complains:
>
> Thanks, updated patch attached.
Applied, with some minor tweaks, thanks.
I didn't try the WIN32 compile. I hope I didn't
Heikki,
> The FSM is included in the base backup, and it is updated when VACUUM
> records are replayed.
Oh? H. In that case, the issue I'm seeing in production is
something else. Unless that was a change for 9.1?
> It is also updated when insert/update/delete records are replayed,
> atho
2012/3/19 Qi Huang :
>> I actually tried to find out, personally...not sure if I was searching
>> wrongly, but searching for TABLESAMPLE did not yield a cornucopia of
>> useful conversations at the right time in history (~2007), even when
>> the search is given a broad date-horizon (all), so I, too
Robert Haas writes:
> On Tue, Mar 20, 2012 at 11:50 AM, Tom Lane wrote:
>> I see that patch has not made it to any released versions yet.
>> Is it too late to rethink the design? I propose (a) redefining it
>> as committing after every N objects, and (b) having a limit of 1000
>> or so objects b
Robert Haas writes:
> Yeah, I think I'm going to try implementing
> quicksort-the-whole-batch-and-dump-it-out-as-a-run algorithm, just to
> see how good or bad that is compared to what we have now. We may not
> end up doing anything that remotely resembles that, in the end, but I
> want to see th
On 3/18/12 10:25 AM, Tom Lane wrote:
Jeff Janes writes:
> On Wed, Mar 7, 2012 at 11:55 AM, Robert Haas wrote:
>> On Sat, Mar 3, 2012 at 4:15 PM, Jeff Janes wrote:
>>> Anyway, I think the logtape could use redoing.
> The problem there is that none of the files can be deleted until it
>
Excerpts from Marco Nenciarini's message of mar mar 20 07:53:06 -0300 2012:
> I was trying to compile orafce on the current master and it yield
> an error at line
>
> tupdesc = trigdata->tg_relation->rd_att;
>
> alert.c: In function ‘dbms_alert_defered_signal’:
> alert.c:839:33: error: derefere
> > I think you are asking for this option:
> > -l LIMIT stop after removing LIMIT large objects
> > which was added in b69f2e36402aaa.
Thank you for informing about -l option in 9.2. Can I build/use this contrib
with older pg versions i.e. pg 9.1 ? . Thanks.
> Uh, no, actually that flag s
On Tue, Mar 20, 2012 at 3:41 PM, Greg Stark wrote:
> On Tue, Mar 20, 2012 at 5:04 PM, Robert Haas wrote:
>> No. It does the opposite: it slows it down. This is a highly
>> surprising result but it's quite repeatable: removing comparisons
>> makes it slower. As previously pontificated, I think
On Tue, Mar 20, 2012 at 5:04 PM, Robert Haas wrote:
> No. It does the opposite: it slows it down. This is a highly
> surprising result but it's quite repeatable: removing comparisons
> makes it slower. As previously pontificated, I think this is probably
> because the heap can fill up with next
On Fri, Mar 16, 2012 at 4:44 AM, Etsuro Fujita
wrote:
> I have a plan to support 'Create index on foreign table' for 9.3. Here
> is my plan.
>
> The index creation is supported for a flat file such as CSV and a remote
> table on a RDB e.g., Postgres using CREATE INDEX. (I thought using a
> new s
On Fri, Mar 16, 2012 at 3:44 AM, Yeb Havinga wrote:
> In the patch with copy-editing documentation following that commit, at "in
> at their option", s/in// ?
Oh, yeah. Oops. Thanks.
> Also 'rather than .. as mandated by the system':
> I'm having trouble parsing 'as'. It is also unclear to me w
On Tue, Mar 20, 2012 at 12:34 PM, Atri Sharma wrote:
>
>
> -Original Message-
> From: Merlin Moncure [mailto:mmonc...@gmail.com]
> Sent: 20 March 2012 22:50
> To: Atri Sharma
> Cc: Heikki Linnakangas; Alvaro Herrera; Daniel Farina; Andrew Dunstan; Dave
> Page; Pg Hackers
> Subject: Re: [HA
On 20 March 2012 17:49, Dimitri Fontaine wrote:
> Hi,
>
> I guess I sent v17 a little early considering that we now already have
> v18 including support for CREATE TABLE AS and SELECT INTO, thanks to the
> work of Andres and Tom.
>
> There was some spurious tags in the sgml files in v17 that I did
Peter Eisentraut writes:
> As you can see, pgindent adds whitespace on top of #ifdef
> USE_ASSERT_CHECKING, and messes up the vertical alignment of variable
> definitions that contain extra attributes.
Hm. I bet it thinks that PG_USED_FOR_ASSERTS_ONLY is the variable name,
which means that the b
On tis, 2012-01-24 at 13:18 -0500, Tom Lane wrote:
> Robert Haas writes:
> > Yes, that's what I meant when I suggested it originally. I'm just not
> > sure it's any nicer than adding ifdefs for USE_ASSERT_CHECKING.
>
> I'm inclined to think that it probably is nicer, just because of less
> verti
On Tue, Mar 20, 2012 at 10:13 AM, Tom Lane wrote:
> Robert Haas writes:
>> Maybe we should just not worry about this.
>
> That's been my reaction right along. There's no evidence that PID
> recycling is a problem in the real world.
I'm entirely willing to acquiesce to that point of view. I onl
Tom Lane writes:
> I've applied the CTAS patch after rather heavy editorialization. Don't
> know what consequences that will have for Dimitri's patch.
It allows my patch to add support for CREATE TABLE AS and SELECT INTO,
I've been doing that and am on my way to sending a v18 now. The way you
wo
-Original Message-
From: Merlin Moncure [mailto:mmonc...@gmail.com]
Sent: 20 March 2012 22:50
To: Atri Sharma
Cc: Heikki Linnakangas; Alvaro Herrera; Daniel Farina; Andrew Dunstan; Dave
Page; Pg Hackers
Subject: Re: [HACKERS] Regarding column reordering project for GSoc 2012
On Tue, Mar
On Mon, Mar 19, 2012 at 08:48:07PM +, Peter Geoghegan wrote:
> On 19 March 2012 19:55, Peter Eisentraut wrote:
> > If someone wanted to bite the bullet and do the work, I think we could
> > move to a Perl/TAP-based test suite (not pgTAP, but Perl and some fairly
> > standard Test::* modules) a
On Tue, Mar 20, 2012 at 11:57 AM, Atri Sharma wrote:
>
>
> -Original Message-
> From: Merlin Moncure [mailto:mmonc...@gmail.com]
> Sent: 20 March 2012 20:52
> To: Atri Sharma
> Cc: Heikki Linnakangas; Alvaro Herrera; Daniel Farina; Andrew Dunstan; Dave
> Page; Pg Hackers
> Subject: Re: [HA
Robert Haas writes:
> Maybe we should just not worry about this.
That's been my reaction right along. There's no evidence that PID
recycling is a problem in the real world.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On Tue, Mar 20, 2012 at 12:48 PM, Tom Lane wrote:
> Robert Haas writes:
>> Well, I'm not sure it would save anything meaningful to read the PID
>> after releasing the lock even if it were safe, so I'd be inclined to
>> keep things simple. But on further reflection I had us using the PID
>> to fi
On Tue, Mar 20, 2012 at 12:33 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Mar 20, 2012 at 7:44 AM, Greg Stark wrote:
>>> Offhand I wonder if this is all because we don't have the O(n) heapify
>>> implemented.
>
>> I'm pretty sure that's not the problem. Even though our heapify is
>> no
-Original Message-
From: Merlin Moncure [mailto:mmonc...@gmail.com]
Sent: 20 March 2012 20:52
To: Atri Sharma
Cc: Heikki Linnakangas; Alvaro Herrera; Daniel Farina; Andrew Dunstan; Dave
Page; Pg Hackers
Subject: Re: [HACKERS] Regarding column reordering project for GSoc 2012
On Tue, Mar
Robert Haas writes:
> Well, I'm not sure it would save anything meaningful to read the PID
> after releasing the lock even if it were safe, so I'd be inclined to
> keep things simple. But on further reflection I had us using the PID
> to find the target PGPROC in the first place, so we don't need
On Tue, Mar 20, 2012 at 4:35 AM, Daniel Farina wrote:
> I chose the SessionId mostly because I didn't have a great sense
> around how hot the ProcArrayLock is, and it was easy to add a
> fine-grained spinlock to just get the flavor of the idea.
It's fairly hot, but terminating or canceling backen
Robert Haas writes:
> On Tue, Mar 20, 2012 at 7:44 AM, Greg Stark wrote:
>> Offhand I wonder if this is all because we don't have the O(n) heapify
>> implemented.
> I'm pretty sure that's not the problem. Even though our heapify is
> not as efficient as it could be, it's plenty fast enough. I
On Tue, Mar 20, 2012 at 12:12 PM, Tom Lane wrote:
> Greg Stark writes:
>> http://en.wikipedia.org/wiki/Binary_heap#Building_a_heap
>
> Interesting. I'm pretty sure that idea appears nowhere in Knuth
> (which might mean it's new enough to have a live patent on it ...
> anybody know who invented t
On Tue, Mar 20, 2012 at 7:44 AM, Greg Stark wrote:
> On Tue, Mar 20, 2012 at 1:57 AM, Tom Lane wrote:
>> That was a long time ago, of course, but I have some vague recollection
>> that keeping next-run tuples in the current heap achieves a net savings
>> in the total number of comparisons needed
Greg Stark writes:
> http://en.wikipedia.org/wiki/Binary_heap#Building_a_heap
Interesting. I'm pretty sure that idea appears nowhere in Knuth
(which might mean it's new enough to have a live patent on it ...
anybody know who invented this?). But it seems like that should buy
back enough compari
Excerpts from Jeff Janes's message of mar mar 20 12:54:55 -0300 2012:
> On Mon, Mar 19, 2012 at 12:29 PM, Alvaro Herrera
> wrote:
> > Did you have a look at the TODO list? http://wiki.postgresql.org/wiki/Todo
>
> However, the new user should be aware that many of the things in that
> list are
On Tuesday, February 28, 2012 12:43:02 AM Andres Freund wrote:
> On Tuesday, February 28, 2012 12:30:36 AM Tom Lane wrote:
> > Andres Freund writes:
> > > Sorry for letting this slide.
> > >
> > > Is it worth adding this bit to OpenIntoRel? Not sure if there is danger
> > > in allowing anyone to
On Tuesday, March 20, 2012 02:39:56 AM Tom Lane wrote:
> I've applied the CTAS patch after rather heavy editorialization. Don't
> know what consequences that will have for Dimitri's patch.
Thanks for all the work you put into this! Looks cleaner now...
Thanks,
Andres
--
Sent via pgsql-hackers
On Tue, Mar 20, 2012 at 11:50 AM, Tom Lane wrote:
> Josh Kupershmidt writes:
>> On Tue, Mar 20, 2012 at 7:53 AM, Tom Lane wrote:
>>> I'm not entirely convinced that that was a good idea. However, so far
>>> as vacuumlo is concerned, the only reason this is a problem is that
>>> vacuumlo goes out
On Mon, Mar 19, 2012 at 12:29 PM, Alvaro Herrera
wrote:
>
> Excerpts from Atri Sharma's message of lun mar 19 16:20:09 -0300 2012:
>
>> I was just going through PGfoundry and I think I will be able to work
>> on the PL/Java project.Please let me know If I can proceed further on
>> ot for GSOC and
Josh Kupershmidt writes:
> On Tue, Mar 20, 2012 at 7:53 AM, Tom Lane wrote:
>> I'm not entirely convinced that that was a good idea. However, so far
>> as vacuumlo is concerned, the only reason this is a problem is that
>> vacuumlo goes out of its way to do all the large-object deletions in a
>>
=?UTF-8?B?0JTQvNC40YLRgNC40Lk=?= writes:
> Running PostgreSQL 8.4.8 on x86_64-pc-linux-gnu, compiled by GCC
> gcc-4.6.real (Ubuntu/Linaro 4.6.0-7ubuntu1) 4.6.1, 64-bit
> under Ubuntu 11.10.
> with uuu as (
> select dml.id
>from mp_locs12 dml
> where (complex conditions, leaving
On Tue, Mar 20, 2012 at 6:31 AM, Tom Lane wrote:
> Greg Stark writes:
>> Offhand I wonder if this is all because we don't have the O(n) heapify
>> implemented.
I think we do already have it implemented. 1/2 the time the tuple
stays where it is after one comparison, 1/4 it moves up one level wit
http://en.wikipedia.org/wiki/Binary_heap#Building_a_heap
--
greg
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Mar 20, 2012 at 7:53 AM, Tom Lane wrote:
> I'm not entirely convinced that that was a good idea. However, so far
> as vacuumlo is concerned, the only reason this is a problem is that
> vacuumlo goes out of its way to do all the large-object deletions in a
> single transaction. What's th
On Tue, Mar 20, 2012 at 6:58 AM, Atri Sharma wrote:
> -Original Message-
> From: Merlin Moncure [mailto:mmonc...@gmail.com]
> Sent: 20 March 2012 03:15
> To: Heikki Linnakangas
> Cc: Alvaro Herrera; Atri Sharma; Daniel Farina; Andrew Dunstan; Dave Page;
> Pg Hackers
> Subject: Re: [HACKERS
MUHAMMAD ASIF wrote:
> We have noticed the following issue with vacuumlo database that have millions
> of record
> in pg_largeobject i.e.
[...]
> ~/work/pg/postgresql-9.1.2/inst$ bin/vacuumlo vacuumlo_test
>
> WARNING: out of shared memory
> Failed to remove lo 36726: ERROR: out of shared mem
MUHAMMAD ASIF writes:
> We have noticed the following issue with vacuumlo database that have millions
> of record in pg_largeobject i.e.
>WARNING: out of shared memoryFailed to remove lo 155987:ERROR: out
> of shared memory HINT: You might need to increase
> max_locks_per_transacti
Excerpts from Marco Nenciarini's message of mar mar 20 07:53:06 -0300 2012:
> I was trying to compile orafce on the current master and it yield
> an error at line
>
> tupdesc = trigdata->tg_relation->rd_att;
>
> alert.c: In function ‘dbms_alert_defered_signal’:
> alert.c:839:33: error: dereferen
Hitoshi Harada writes:
> I've noticed our plv8 regression test now fails. It has CREATE DOMAIN
> json AS text ... and validates text via v8's JSON.parse(), which was
> working before introducing built-in json type. The test itself can be
> solved simply by creating schema, but my surprise is tha
Greg Stark writes:
> Offhand I wonder if this is all because we don't have the O(n) heapify
> implemented.
Robert muttered something about that before, but is it real? If you
could do that, I'd think you'd have a less-than-n-log-n sorting
solution.
regards, tom lane
--
-Original Message-
From: Heikki Linnakangas [mailto:heikki.linnakan...@enterprisedb.com]
Sent: 20 March 2012 17:39
To: Claes Jakobsson
Cc: Merlin Moncure; Alvaro Herrera; Atri Sharma; Daniel Farina; Andrew
Dunstan; Dave Page; Pg Hackers
Subject: Re: [HACKERS] Regarding column reordering pr
On 20.03.2012 11:10, Claes Jakobsson wrote:
On 19 mar 2012, at 22.45, Merlin Moncure wrote:
one pl/java based project that IMO is just screaming to be done is a
pl/java based FDW (wrapping JDBC) that would approximately reproduce
dblink...maybe with some extra features geared towards ETL type jo
-Original Message-
From: Merlin Moncure [mailto:mmonc...@gmail.com]
Sent: 20 March 2012 03:15
To: Heikki Linnakangas
Cc: Alvaro Herrera; Atri Sharma; Daniel Farina; Andrew Dunstan; Dave Page;
Pg Hackers
Subject: Re: [HACKERS] Regarding column reordering project for GSoc 2012
On Mon, Mar 1
-Original Message-
From: Claes Jakobsson [mailto:cl...@versed.se]
Sent: 20 March 2012 14:40
To: Merlin Moncure
Cc: Heikki Linnakangas; Alvaro Herrera; Atri Sharma; Daniel Farina; Andrew
Dunstan; Dave Page; Pg Hackers
Subject: Re: [HACKERS] Regarding column reordering project for GSoc 201
Il giorno mar, 20/03/2012 alle 16.46 +0500, Asif Naeem ha scritto:
> It seems that compiler is complain about "Relation" structure, can you
> please try adding the following in trigtest.c i.e.
>
> #include "utils/rel.h"
>
It does the trick.
Regards,
Marco
--
Marco Nenciarini - 2ndQuadrant Ita
It seems that compiler is complain about "Relation" structure, can you
please try adding the following in trigtest.c i.e.
#include "utils/rel.h"
Best Regards,
Asif Naeem
On Tue, Mar 20, 2012 at 3:53 PM, Marco Nenciarini <
marco.nenciar...@2ndquadrant.it> wrote:
> I was trying to compile orafce
On Tue, Mar 20, 2012 at 1:57 AM, Tom Lane wrote:
> That was a long time ago, of course, but I have some vague recollection
> that keeping next-run tuples in the current heap achieves a net savings
> in the total number of comparisons needed to heapify both runs.
Offhand I wonder if this is all be
Il giorno mar, 20/03/2012 alle 11.16 +, Peter Geoghegan ha scritto:
> On 20 March 2012 10:53, Marco Nenciarini
> wrote:
> > alert.c: In function ‘dbms_alert_defered_signal’:
> > alert.c:839:33: error: dereferencing pointer to incomplete type
> > make: *** [alert.o] Error 1
> >
> > I've also tr
On 20 March 2012 10:53, Marco Nenciarini
wrote:
> alert.c: In function ‘dbms_alert_defered_signal’:
> alert.c:839:33: error: dereferencing pointer to incomplete type
> make: *** [alert.o] Error 1
>
> I've also tried the example at
>
> http://www.postgresql.org/docs/devel/static/trigger-example.htm
I was trying to compile orafce on the current master and it yield
an error at line
tupdesc = trigdata->tg_relation->rd_att;
alert.c: In function ‘dbms_alert_defered_signal’:
alert.c:839:33: error: dereferencing pointer to incomplete type
make: *** [alert.o] Error 1
I've also tried the example a
I have reformatted the mail, sorry for inconvenience. Thanks.
We have noticed the following issue with vacuumlo database that have millions
of record in pg_largeobject i.e. WARNING: out of shared memory
Failed to remove lo 155987:ERROR: out of shared memory HINT: You
m
Hi,
We have noticed the following issue with vacuumlo database that have millions
of record in pg_largeobject i.e.
WARNING: out of shared memoryFailed to remove lo 155987: ERROR: out of
shared memory HINT: You might need to increase max_locks_per_transaction.
Why do we need to increa
On Tue, Mar 20, 2012 at 2:47 AM, Abel Abraham Camarillo Ojeda
wrote:
> On Tue, Mar 20, 2012 at 2:44 AM, Hitoshi Harada wrote:
>> I've noticed our plv8 regression test now fails. It has CREATE DOMAIN
>> json AS text ... and validates text via v8's JSON.parse(), which was
>> working before introdu
On Tue, Mar 20, 2012 at 2:44 AM, Hitoshi Harada wrote:
> I've noticed our plv8 regression test now fails. It has CREATE DOMAIN
> json AS text ... and validates text via v8's JSON.parse(), which was
> working before introducing built-in json type. The test itself can be
> solved simply by creatin
I've noticed our plv8 regression test now fails. It has CREATE DOMAIN
json AS text ... and validates text via v8's JSON.parse(), which was
working before introducing built-in json type. The test itself can be
solved simply by creating schema, but my surprise is that we allow a
domain whose name i
On Mon, Mar 19, 2012 at 9:08 PM, Robert Haas wrote:
> It's after midnight here so maybe I'm being slow, but I don't
> understand what problem the SessionId solves. ISTM that you could
> solve the problem like this:
>
> 1. Acquire ProcArrayLock in exclusive mode, to keep the set of PGPROCs
> from
On Thu, Mar 15, 2012 at 9:39 PM, Fujii Masao wrote:
> On Fri, Mar 16, 2012 at 8:14 AM, Daniel Farina wrote:
>> Parallel to pg_cancel_backend, it'd be nice to allow the user to just
>> outright kill a backend that they own (politely, with a SIGTERM),
>> aborting any transactions in progress, inclu
Running PostgreSQL 8.4.8 on x86_64-pc-linux-gnu, compiled by GCC
gcc-4.6.real (Ubuntu/Linaro 4.6.0-7ubuntu1) 4.6.1, 64-bit
under Ubuntu 11.10.
Got large table with geography (PostGIS 1.5) data, running two almost
same queries with same result, but very different performance.
First query:
wit
70 matches
Mail list logo
