On Thu, Apr 3, 2014 at 11:44 PM, Tom Lane wrote:
> Personally, I have paid no attention to this thread and have no intention
> of doing so before feature freeze.
Anything that you missed was likely musings on how to further
generalize SortSupport. The actual additions to SortSupport and
tuplesort
On Tue, Apr 1, 2014 at 11:42 PM, Pavel Stehule wrote:
> 2014-03-27 17:56 GMT+01:00 Pavel Stehule :
>> So I'll prepare a some prototypes in next month for
>>
>> 1. log a execution time for cancelled queries,
>> 2. track a query lock time
>>
>
> When I though about this proposal, I found so our impl
If I understand correctly, foreign tables cannot have an OID column, but
the following code in DefineRelation() assumes that foreign tables *can*
have that coulum:
560 /*
561 * Create a tuple descriptor from the relation schema. Note
that this
562 * deals with column names, types, a
On Fri, Apr 04, 2014 at 02:36:05AM +, YAMAMOTO Takashi wrote:
> > Thanks. To avoid socket path length limitations, I lean toward placing the
> > socket temporary directory under /tmp rather than placing under the CWD:
> >
> > http://www.postgresql.org/message-id/flat/20121129223632.ga15...@to
Peter Geoghegan writes:
> I think that those are objectively very large reductions in a cost
> that figures prominently in most workloads. Based solely on those
> facts, but also on the fairly low complexity of the patch, it may be
> worth considering committing this before 9.4 goes into feature f
On Thu, Apr 3, 2014 at 3:19 PM, Thom Brown wrote:
> Master: 38.450082 / 37.440701 (avg: 37.9453915)
> Patch: 153.321946 / 145.004726 (avg: 149.163336)
I think that those are objectively very large reductions in a cost
that figures prominently in most workloads. Based solely on those
facts, but al
> Thanks. To avoid socket path length limitations, I lean toward placing the
> socket temporary directory under /tmp rather than placing under the CWD:
>
> http://www.postgresql.org/message-id/flat/20121129223632.ga15...@tornado.leadboat.com
openvswitch has some tricks to overcome the socket pat
On 2014-04-03 19:33:12 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-04-03 19:08:27 -0400, Tom Lane wrote:
> >> A somewhat more relevant concern is where are we going to keep the state
> >> data involved in all this. Since this code is, by definition, going to be
> >> called in criti
Andres Freund writes:
> On 2014-04-03 19:08:27 -0400, Tom Lane wrote:
>> A somewhat more relevant concern is where are we going to keep the state
>> data involved in all this. Since this code is, by definition, going to be
>> called in critical sections, any solution involving internal pallocs is
On 2014-04-03 19:08:27 -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Thu, Apr 3, 2014 at 10:14 AM, Heikki Linnakangas
> > wrote:
> >> (Instead of using a new XLogRegisterBuffer() function to register the
> >> buffers, perhaps they should be passed to XLogInsert as a separate list or
> >> ar
I wrote:
> Robert Haas writes:
>> Well, that argues for the choice of trying to make them equivalent
>> again, I suppose, but it sounds like there are some nasty edge cases
>> that won't easily be filed down. I think your idea of redefining
>> funcvariadic to be true only for VARIADIC ANY is prob
Robert Haas writes:
> On Thu, Apr 3, 2014 at 10:14 AM, Heikki Linnakangas
> wrote:
>> (Instead of using a new XLogRegisterBuffer() function to register the
>> buffers, perhaps they should be passed to XLogInsert as a separate list or
>> array. I'm not wedded on the details...)
> That would have
=?koi8-r?B?98/Sz87JziDkzcnU0snK?= writes:
> I know it. So, my second questions is:
> How can I add support of this extension in PostgreSQL. So, I want to do
> thing, that PostgreSQL accept connection with cert auth method and
> certificate has my extension with critical flag?
Seems like this is
On Thu, Apr 3, 2014 at 10:14 AM, Heikki Linnakangas
wrote:
> (Instead of using a new XLogRegisterBuffer() function to register the
> buffers, perhaps they should be passed to XLogInsert as a separate list or
> array. I'm not wedded on the details...)
That would have the advantage of avoiding the
Thank you for answer!
I know it. So, my second questions is:
How can I add support of this extension in PostgreSQL. So, I want to do thing,
that PostgreSQL accept connection with cert auth method and certificate has my
extension with critical flag?
03.04.2014, 04:33, "Wim Lewis" :
> On 1 Apr 201
Dear Hackers,
We at Citus Data have been developing a columnar store extension for
PostgreSQL. Today we are excited to open source it under the Apache v2.0
license.
This columnar store extension uses the Optimized Row Columnar (ORC) format
for its data layout, which improves upon the RCFile forma
Good afternoon all.I have some problem with triggers on PostgreSQL 8.4.I have
a trigger on specific table(articles) that fires on update statement:
CREATE OR REPLACE FUNCTION trigger_articles_update()
RETURNS trigger AS
$BODY$BEGIN
INSERT INTO
article_change(article_id,change_type)VALUES(
Alvaro Herrera writes:
> Stephen Frost wrote:
>> Add ALTER TABLESPACE ... MOVE command
> I just noticed that this commit added the new commands under the
> "ALTER THING name RENAME TO" production (which were originally for
> RenameStmt); since commit d86d51a95 had already added some
> AlterTableS
On Thu, Apr 3, 2014 at 11:21 PM, Heikki Linnakangas wrote:
> On 04/03/2014 04:15 PM, Alexander Korotkov wrote:
>
>> On Wed, Apr 2, 2014 at 2:22 PM, Alexander Korotkov > >wrote:
>>
>> On Tue, Apr 1, 2014 at 2:23 PM, Heikki Linnakangas <
>>> hlinnakan...@vmware.com> wrote:
>>>
>>> The BIRCH algor
On 04/03/2014 04:15 PM, Alexander Korotkov wrote:
On Wed, Apr 2, 2014 at 2:22 PM, Alexander Korotkov wrote:
On Tue, Apr 1, 2014 at 2:23 PM, Heikki Linnakangas <
hlinnakan...@vmware.com> wrote:
The BIRCH algorithm as described in the paper describes building a tree
in memory. If I understood c
On 3 April 2014 19:05, Peter Geoghegan wrote:
> On Thu, Apr 3, 2014 at 1:23 PM, Thom Brown wrote:
>> I'm getting an error when building this:
>
> Sorry. I ran this through Valgrind, and forgot to reset where the
> relevant macro is define'd before submission. Attached revision should
> build with
Stephen Frost wrote:
> Add ALTER TABLESPACE ... MOVE command
>
> This adds a 'MOVE' sub-command to ALTER TABLESPACE which allows moving sets of
> objects from one tablespace to another. This can be extremely handy and
> avoids
> a lot of error-prone scripting. ALTER TABLESPACE ... MOVE will onl
On 03/27/2014 01:09 PM, Tom Lane wrote:
Alvaro Herrera writes:
Note that "make check" in contrib is substantially slower than "make
installcheck" --- it creates a temporary installation for each contrib
module. If we make buildfarm run installcheck for all modules, that
might be a problem for
On Thu, Apr 3, 2014 at 1:23 PM, Thom Brown wrote:
> I'm getting an error when building this:
Sorry. I ran this through Valgrind, and forgot to reset where the
relevant macro is define'd before submission. Attached revision should
build without issue.
--
Peter Geoghegan
*** a/src/backend/execut
On 3 April 2014 17:52, Peter Geoghegan wrote:
> On Mon, Mar 31, 2014 at 7:35 PM, Peter Geoghegan wrote:
>> Okay. Attached revision only trusts strxfrm() blobs (as far as that
>> goes) when the buffer passed to strxfrm() was sufficiently large that
>> the blob could fully fit.
>
> Attached revisio
On Mon, Mar 31, 2014 at 7:35 PM, Peter Geoghegan wrote:
> Okay. Attached revision only trusts strxfrm() blobs (as far as that
> goes) when the buffer passed to strxfrm() was sufficiently large that
> the blob could fully fit.
Attached revision has been further polished. I've added two additional
Dear Hackers,
We at Citus Data have been developing a columnar store extension for
PostgreSQL. Today we are excited to open source it under the Apache v2.0
license.
This columnar store extension uses the Optimized Row Columnar (ORC) format
for its data layout, which improves upon the RCFile forma
On 04/03/2014 07:11 PM, Tom Lane wrote:
More generally, I'm pretty sure that your proposal is already going to
involve some small growth of WAL records compared to today,
Quite possible.
but I think
that's probably all right; the benefits seem significant.
Yep.
OTOH, once we store the rel
Heikki Linnakangas writes:
> On 04/03/2014 06:37 PM, Tom Lane wrote:
>> +1, but one important step here is finding the data to be replayed.
>> That is, a large part of the complexity of replay routines has to do
>> with figuring out which parts of the WAL record were elided due to
>> full-page-ima
On 04/03/2014 06:37 PM, Tom Lane wrote:
Also, IIRC there are places that WAL-log full pages that aren't in a
shared buffer at all (btree build does this I think). How will that fit
into this model?
Hmm. We could provide a function for registering a block with given
content, without a Buffer.
On 04/03/2014 12:01 AM, Tom Lane wrote:
Andrew Dunstan writes:
For OSX we'd construct the list via File::Find to recurse through the
directories.
So, something like this:
Thanks for the tips. The attached patch against buildfarm 4.11 seems
to work, cf
http://buildfarm.postgresql.org/cgi-bin/
Heikki Linnakangas writes:
> The big change in creating WAL records is that the buffers involved in
> the WAL-logged operation are explicitly registered, by calling a new
> XLogRegisterBuffer function.
Seems reasonable, especially if we can make the buffer numbering business
less error-prone.
On 2014-04-02 23:50:19 +0200, Andres Freund wrote:
> > > I just tried it on clang. It builds clean with -Wc11-extensions except
> > > warning about _Static_assert(). That's possibly fixable with some
> > > autoconf trickery.
> >
> > Ah. That sounds promising. What clang version is that?
>
> It'
On Thu, Apr 3, 2014 at 7:43 AM, Andrew Dunstan wrote:
> I don't think we should follow these rules at all. Json is not Javascript,
> and these are Javascript rules, not Json rules. I'm entirely opposed to
> treating 0, "0", false, and [0] as equal. The equality rule we actually have
> for jsonb is
On 2014-04-03 10:15:33 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-04-03 09:43:20 -0400, Tom Lane wrote:
> >> I object to the latter; you're proposing to greatly increase the warning
> >> noise seen with any compiler that issues a warning for this without caring
> >> about .h vs .c.
On 2014-04-03 09:43:20 -0400, Tom Lane wrote:
> Andres Freund writes:
> > The current quiet inline test doesn't work for clang. As e.g. evidenced in
> > http://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=gull&dt=2014-04-03%2007%3A49%3A26&stg=configure
> > configure thinks it's not quiet.
Andres Freund writes:
> On 2014-04-03 09:43:20 -0400, Tom Lane wrote:
>> I object to the latter; you're proposing to greatly increase the warning
>> noise seen with any compiler that issues a warning for this without caring
>> about .h vs .c. For somebody who finds gcc -pedantic unusable, I would
I'd like to do some changes to the WAL format in 9.5. I want to annotate
each WAL record with the blocks that they modify. Every WAL record
already includes that information, but it's done in an ad hoc way,
differently in every rmgr. The RelFileNode and block number are
currently part of the WA
Heikki Linnakangas writes:
> No-one's replied yet, but perhaps the worry is that after you've written
> the commit record, you have to go ahead with removing/creating the init
> fork, and that is seen as too risky. If a creat() or unlink() call
> fails, that will have to be a PANIC, and crash r
On 2014-04-03 09:43:20 -0400, Tom Lane wrote:
> Andres Freund writes:
> > The current quiet inline test doesn't work for clang. As e.g. evidenced in
> > http://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=gull&dt=2014-04-03%2007%3A49%3A26&stg=configure
> > configure thinks it's not quiet.
Andres Freund writes:
> The current quiet inline test doesn't work for clang. As e.g. evidenced in
> http://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=gull&dt=2014-04-03%2007%3A49%3A26&stg=configure
> configure thinks it's not quiet.
> Which means that postgres compiled with a recent c
On Wed, Apr 2, 2014 at 2:22 PM, Alexander Korotkov wrote:
> On Tue, Apr 1, 2014 at 2:23 PM, Heikki Linnakangas <
> hlinnakan...@vmware.com> wrote:
>
>> The BIRCH algorithm as described in the paper describes building a tree
>> in memory. If I understood correctly, you're suggesting to use a pre-bu
On 2014-04-03 15:02:27 +0300, Heikki Linnakangas wrote:
> On 04/03/2014 02:41 PM, Andres Freund wrote:
> >On 2014-04-03 13:38:29 +0300, Heikki Linnakangas wrote:
> >>On 04/01/2014 08:58 PM, Andres Freund wrote:
> >>>On 2014-04-01 12:56:04 -0500, Jim Nasby wrote:
> On 3/4/14, 8:50 AM, Andres Fre
On 04/03/2014 04:32 AM, Oleg Bartunov wrote:
> Hi there,
>
> I'm wondering if we should follow all js equility rules as
> nicely visualized in
> http://strilanc.com/visualization/2014/03/27/Better-JS-Equality-Table.html
Probably not as JSON is general interchange format.
If somebody wants JavaScri
On 04/03/2014 02:41 PM, Andres Freund wrote:
On 2014-04-03 13:38:29 +0300, Heikki Linnakangas wrote:
On 04/01/2014 08:58 PM, Andres Freund wrote:
On 2014-04-01 12:56:04 -0500, Jim Nasby wrote:
On 3/4/14, 8:50 AM, Andres Freund wrote:
Can't that be solved by just creating the permanent relatio
On 04/03/2014 05:02 AM, Oleg Bartunov wrote:
Well, we don't supported Infinity and NaN in json(b), as well as Json
standard :)
Now we need a script, which generated nice html table.
(Oleg, please try not to top-post.)
I don't think we should follow these rules at all. Json is not
Javascript,
On 2014-04-03 13:38:29 +0300, Heikki Linnakangas wrote:
> On 04/01/2014 08:58 PM, Andres Freund wrote:
> >On 2014-04-01 12:56:04 -0500, Jim Nasby wrote:
> >>On 3/4/14, 8:50 AM, Andres Freund wrote:
> >>>Can't that be solved by just creating the permanent relation in a new
> >>>relfilenode? That's e
On 2014-04-03 14:26:50 +0300, Heikki Linnakangas wrote:
> On 04/01/2014 08:39 PM, Heikki Linnakangas wrote:
> >On 03/07/2014 05:36 AM, Tom Lane wrote:
> >>=?ISO-8859-1?Q?Fabr=EDzio_de_Royes_Mello?= writes:
> >>>Do you think is difficult to implement "ALTER TABLE ... SET UNLOGGED" too?
> >>>Thinkin
On 04/01/2014 08:39 PM, Heikki Linnakangas wrote:
On 03/07/2014 05:36 AM, Tom Lane wrote:
=?ISO-8859-1?Q?Fabr=EDzio_de_Royes_Mello?= writes:
Do you think is difficult to implement "ALTER TABLE ... SET UNLOGGED" too?
Thinking in a scope of one GSoC, of course.
I think it's basically the same
On 2014-04-01 20:39:35 +0300, Heikki Linnakangas wrote:
> On 03/07/2014 05:36 AM, Tom Lane wrote:
> >=?ISO-8859-1?Q?Fabr=EDzio_de_Royes_Mello?= writes:
> >>Do you think is difficult to implement "ALTER TABLE ... SET UNLOGGED" too?
> >>Thinking in a scope of one GSoC, of course.
> >
> >I think it's
On 04/03/2014 01:44 PM, Andres Freund wrote:
On 2014-04-03 13:38:29 +0300, Heikki Linnakangas wrote:
On 04/01/2014 08:58 PM, Andres Freund wrote:
On 2014-04-01 12:56:04 -0500, Jim Nasby wrote:
On 3/4/14, 8:50 AM, Andres Freund wrote:
Can't that be solved by just creating the permanent relatio
Hi,
The current quiet inline test doesn't work for clang. As e.g. evidenced in
http://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=gull&dt=2014-04-03%2007%3A49%3A26&stg=configure
configure thinks it's not quiet.
Which means that postgres compiled with a recent clang will be noticably
slo
On 2014-04-03 13:38:29 +0300, Heikki Linnakangas wrote:
> On 04/01/2014 08:58 PM, Andres Freund wrote:
> >On 2014-04-01 12:56:04 -0500, Jim Nasby wrote:
> >>On 3/4/14, 8:50 AM, Andres Freund wrote:
> >>>Can't that be solved by just creating the permanent relation in a new
> >>>relfilenode? That's e
On 04/01/2014 08:58 PM, Andres Freund wrote:
On 2014-04-01 12:56:04 -0500, Jim Nasby wrote:
On 3/4/14, 8:50 AM, Andres Freund wrote:
Can't that be solved by just creating the permanent relation in a new
relfilenode? That's equivalent to a rewrite, yes, but we need to do that
for anything but wa
On 2014-04-03 00:48:12 -0400, Greg Stark wrote:
> On Wed, Apr 2, 2014 at 4:16 PM, Andres Freund wrote:
> > PS: Could you please start to properly quote again? You seem to have
> > stopped doing that entirely in the last few months.
>
> I've been responding a lot from the phone. Unfortunately the Gm
Well, we don't supported Infinity and NaN in json(b), as well as Json
standard :)
Now we need a script, which generated nice html table.
On Thu, Apr 3, 2014 at 12:40 PM, Yeb Havinga wrote:
> On 2014-04-03 09:40, Oleg Bartunov wrote:
>>
>> Sure, we don't follow. I mean should we add to documentati
On 2014-04-03 09:40, Oleg Bartunov wrote:
Sure, we don't follow. I mean should we add to documentation
such matrices.
Oleg
On Thu, Apr 3, 2014 at 11:32 AM, Oleg Bartunov wrote:
Hi there,
I'm wondering if we should follow all js equility rules as
nicely visualized in
http://strilanc.com/visua
Sure, we don't follow. I mean should we add to documentation
such matrices.
Oleg
On Thu, Apr 3, 2014 at 11:32 AM, Oleg Bartunov wrote:
> Hi there,
>
> I'm wondering if we should follow all js equility rules as
> nicely visualized in
> http://strilanc.com/visualization/2014/03/27/Better-JS-Equali
Hi there,
I'm wondering if we should follow all js equility rules as
nicely visualized in
http://strilanc.com/visualization/2014/03/27/Better-JS-Equality-Table.html
Oleg
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postg
Hi Michael,
The problem of offsets seems to be universal. If there is a structure
within structure. The offset to the members of inner structure should be
the size of the outer structure and not size of inner structure. Applying
this rule recursively, offset to the member of any nested structure, a
60 matches
Mail list logo
