Hi,
Attached does:
s/pg_replication_origin_xact-setup/pg_replication_origin_xact_setup/g
or, (s/-/_/g)
Thanks,
Amit
diff --git a/doc/src/sgml/replication-origins.sgml b/doc/src/sgml/replication-origins.sgml
index c531022..0cd08ee 100644
--- a/doc/src/sgml/replication-origins.sgml
+++ b/doc/src/
Has there been any movement on this in the last couple years?
I could really use the ability to optimize across CTE boundaries, and it
seems like a lot of other people could too.
> "Andres" == Andres Freund writes:
Andres> This is not a real review. I'm just scanning through the
Andres> patch, without reading the thread, to understand if I see
Andres> something "worthy" of controversy. While scanning I might have
Andres> a couple observations or questions.
>> +
On Tue, Apr 28, 2015 at 2:31 AM, Jim Nasby wrote:
>
> On 4/25/15 12:12 AM, Amit Kapila wrote:
>>
>> > ... which isn't possible. You can not go from a heap tuple to an
>> index tuple.
>>
>> We will have the access to index value during delete, so why do you
>> think that we need linkage between he
On Wed, Apr 29, 2015 at 12:17 AM, David Steele wrote:
> On 4/28/15 2:14 AM, Sawada Masahiko wrote:
>> On Fri, Apr 24, 2015 at 3:23 AM, David Steele wrote:
>>> I've also added some checking to make sure that if anything looks funny
>>> on the stack an error will be generated.
>>>
>>> Thanks for th
On Thu, Apr 30, 2015 at 6:31 AM, David Steele wrote:
> On 4/29/15 5:16 PM, Robert Haas wrote:
>> On Fri, Apr 24, 2015 at 2:40 PM, David Steele wrote:
>>>
>>>The view pg_file_settings provides access to
>>> run-time parameters
>>>that are defined in configuration files via SQL. In cont
On Wed, Apr 15, 2015 at 02:59:55PM +0900, Michael Paquier wrote:
> On Wed, Apr 15, 2015 at 2:38 PM, Noah Misch wrote:
> > Solaris 10 ships Perl 5.8.4, and RHEL 5.11 ships Perl 5.8.8. Therefore,
> > Perl
> > installations lacking this File::Path feature will receive vendor support
> > for
> > yea
On Mon, Feb 16, 2015 at 05:03:45PM -0500, Bruce Momjian wrote:
> > All of our makefiles use single quotes, so effectively the only
> > character we don't support in directory paths is the single quote itself.
>
> This seems to say that Windows batch files don't have any special
> meaning for singl
On 04/30/15 02:42, Robert Haas wrote:
On Wed, Apr 29, 2015 at 6:55 PM, Tomas Vondra
wrote:
I'm not convinced not compressing the data is a good idea - it suspect it
would only move the time to TOAST, increase memory pressure (in general and
in shared buffers). But I think that using a more ef
On Wed, Apr 29, 2015 at 8:20 PM, Alvaro Herrera
wrote:
>> Finally, you've got the idea of making pg_ a reserved prefix for
>> roles, adding some predefined roles, and giving them some predefined
>> privileges. That should be yet another patch.
>
> On this part I have a bit of a problem -- the pre
On Wed, Apr 29, 2015 at 6:55 PM, Tomas Vondra
wrote:
> I'm not convinced not compressing the data is a good idea - it suspect it
> would only move the time to TOAST, increase memory pressure (in general and
> in shared buffers). But I think that using a more efficient compression
> algorithm would
On 30/04/15 12:20, Alvaro Herrera wrote:
Robert Haas wrote:
I think that if you commit this the way you have it today, everybody
will go, oh, look, Stephen committed something, but it looks
complicated, I won't pay attention.
Yeah, that sucks.
Finally, you've got the idea of making pg_ a res
Robert Haas wrote:
> I think that if you commit this the way you have it today, everybody
> will go, oh, look, Stephen committed something, but it looks
> complicated, I won't pay attention.
Yeah, that sucks.
> Finally, you've got the idea of making pg_ a reserved prefix for
> roles, adding some
John Gorman writes:
> Two of the trigonometry functions have differing error condition behavior
> between Linux and OSX. The Linux behavior follows the standard set by the
> other trig functions.
We have never considered it part of Postgres' charter to try to hide
platform-specific variations in
Hi,
This is not a real review. I'm just scanning through the patch, without
reading the thread, to understand if I see something "worthy" of
controversy. While scanning I might have a couple observations or
questions.
On 2015-03-13 15:46:15 +, Andrew Gierth wrote:
> + * A list of group
On 30/04/15 00:44, Tom Lane wrote:
Robert Haas writes:
On Mon, Apr 20, 2015 at 9:03 AM, Tomas Vondra
wrote:
Sure, it's not an ultimate solution, but it might help a bit. I do have
other ideas how to optimize this, but in the planner every milisecond
counts. Looking at 'perf top' and seeing pg
On Wed, Apr 29, 2015 at 4:09 PM, Simon Riggs wrote:
> I dislike the way that ignoring objections for a period leads them to be
> potentially discarded. I'd prefer to think that as a community we are able
> to listen to people even when they aren't continually present to reinforce
> the original ob
On 25 April 2015 at 14:05, Peter Geoghegan wrote:
> > a) Why is is 'CONFLICT"? We're talking about a uniquness violation. What
> >if we, at some later point, also want to handle other kind of
> >violations? Shouldn't it be ON UNIQUE CONFLICT/ERROR/VIOLATION ...
>
> I think that naming un
Two of the trigonometry functions have differing error condition behavior
between Linux and OSX. The Linux behavior follows the standard set by the
other trig functions.
On Linux:
SELECT asin(2);
> ERROR: input is out of range
>
SELECT acos(2);
> ERROR: input is out of range
On OSX:
SELECT
On 27/04/15 18:46, Petr Jelinek wrote:
On 18/04/15 20:35, Dmitry Dolgov wrote:
Sorry for late reply. Here is a slightly improved version of the patch
with the new `h_atoi` function, I hope this implementation will be more
appropriate.
It's better, but a) I don't like the name of the function
Hi,
On 04/29/15 23:54, Robert Haas wrote:
On Mon, Apr 20, 2015 at 9:03 AM, Tomas Vondra
wrote:
Sure, it's not an ultimate solution, but it might help a bit. I do have
other ideas how to optimize this, but in the planner every milisecond
counts. Looking at 'perf top' and seeing pglz_decompress(
Robert Haas writes:
> On Mon, Apr 20, 2015 at 9:03 AM, Tomas Vondra
> wrote:
>> Sure, it's not an ultimate solution, but it might help a bit. I do have
>> other ideas how to optimize this, but in the planner every milisecond
>> counts. Looking at 'perf top' and seeing pglz_decompress() in top 3.
On 4/29/15 12:18 PM, Robert Haas wrote:
On Mon, Apr 27, 2015 at 5:01 PM, Jim Nasby wrote:
The problem with just having the value is that if *anything* changes between
how you evaluated the value when you created the index tuple and when you
evaluate it a second time you'll corrupt your index. T
On Thu, Apr 16, 2015 at 3:30 AM, Etsuro Fujita
wrote:
> Attached is a small patch to mark up on with in
> doc/src/sgml/config.sgml.
Committed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@pos
On 2015-04-29 15:31:59 -0400, Robert Haas wrote:
> On Wed, Apr 29, 2015 at 3:13 PM, Stephen Frost wrote:
> >> I still think that constraints should never be named in the syntax.
> >
> > I guess I don't see a particular problem with that..? Perhaps I'm
> > missing something, but if there's multipl
On Sun, Apr 19, 2015 at 11:18 AM, Mikko Tiihonen
wrote:
> I would like allow specifying multiple host names for libpq to try to
> connecting to. This is currently only supported if the host name resolves to
> multiple addresses. Having the support for it without complex dns setup
> would be much e
On Fri, Apr 17, 2015 at 10:27 AM, Tom Lane wrote:
>> The patch will correct it. I have justly copy some code of 'OID'. Whether we
>> need to extract the common code?
>
> This seems like an awful lot of code to solve a problem that will never
> occur in practice.
It does seem like an awful lot of
On Thu, Apr 30, 2015 at 3:30 AM, Andrew Dunstan wrote:
>
> On 04/28/2015 04:10 PM, Andrew Dunstan wrote:
>>
>>
>> On 04/28/2015 12:03 PM, Andrew Dunstan wrote:
>>>
>>>
>>> [switching to -hackers]
>>>
>>> On 04/28/2015 11:51 AM, Andrew Dunstan wrote:
On 04/28/2015 09:04 AM, Michael P
On Mon, Apr 20, 2015 at 9:03 AM, Tomas Vondra
wrote:
> Sure, it's not an ultimate solution, but it might help a bit. I do have
> other ideas how to optimize this, but in the planner every milisecond
> counts. Looking at 'perf top' and seeing pglz_decompress() in top 3.
I suggested years ago that
On 4/29/15 5:16 PM, Robert Haas wrote:
> On Fri, Apr 24, 2015 at 2:40 PM, David Steele wrote:
>>
>>The view pg_file_settings provides access to
>> run-time parameters
>>that are defined in configuration files via SQL. In contrast to
>>pg_settings a row is provided for each
>> occur
On Fri, Apr 24, 2015 at 2:40 PM, David Steele wrote:
>
>The view pg_file_settings provides access to
> run-time parameters
>that are defined in configuration files via SQL. In contrast to
>pg_settings a row is provided for each
> occurrence
>of the parameter in a configuration
On Wed, Apr 29, 2015 at 10:47 AM, Stephen Frost wrote:
> Here is the latest revision of this patch.
I think this patch is too big and does too many things. It should be
broken up into small patches which can be discussed and validated
independently. The fact that your commit message is incredib
On Sun, Apr 26, 2015 at 10:00 PM, Kouhei Kaigai wrote:
> The attached patch v13 is revised one according to the suggestion
> by Robert.
Thanks.
The last hunk in foreign.c is a useless whitespace change.
+ /* actually, not shift members */
Change to: "shift of 0 is the same as copying"
B
On 29/04/15 22:12, David Rowley wrote:
On 25 April 2015 at 00:32, Andres Freund mailto:and...@anarazel.de>> wrote:
Attached is a patch that does this, and some more, renaming. That was
more work than I'd imagined. I've also made the internal naming in
origin.c more consistent/simpl
On Mon, Apr 27, 2015 at 5:05 AM, Shigeru HANADA
wrote:
> Currently INNER JOINs with unsafe join conditions are not pushed down, so
> such test is not in the suit. As you say, in theory, INNER JOINs can be
> pushed down even they have push-down-unsafe join conditions, because such
> conditions
On 25 April 2015 at 00:32, Andres Freund wrote:
>
> Attached is a patch that does this, and some more, renaming. That was
> more work than I'd imagined. I've also made the internal naming in
> origin.c more consistent/simpler and did a bunch of other cleanup.
>
>
Hi,
It looks like bowerbird is
On April 29, 2015 03:09:51 PM Andrew Dunstan wrote:
> On 04/29/2015 01:19 PM, Robert Haas wrote:
> > On Mon, Apr 27, 2015 at 6:41 PM, Andrew Dunstan
wrote:
> >> There's one exception I, at least, have to this rule, namely when there's
> >> a
> >> corresponding compound if or else. I personally fi
Andrew Dunstan wrote:
> It's a matter of taste, but I find things a lot easier to
> understand when they are symmetrical. Thus I like all the
> branches of an "if" to be either in a block or not, and I like
> braces to line up either horizontally or vertically. Perhaps this
> reflects my history,
On Tue, Apr 28, 2015 at 10:00 PM, Peter Eisentraut wrote:
> On 4/24/15 4:29 PM, Andres Freund wrote:
>>> Shouldn't this be backed up by pg_dump(all?)?
>>
>> Given it deals with LSNs and is, quite fundamentally due to concurrency, non
>> transactional, I doubt it's worth it. The other side's slots
On Tue, Apr 28, 2015 at 9:28 PM, Bruce Momjian wrote:
> On Sat, Feb 14, 2015 at 05:29:43PM -0500, Robert Haas wrote:
>> On Sat, Feb 14, 2015 at 5:12 PM, Tom Lane wrote:
>> > Robert Haas writes:
>> >> I think this is probably a holdover from before the death of
>> >> SnapshotNow, and that we shou
On Tue, Apr 28, 2015 at 09:15:49AM -0400, Bruce Momjian wrote:
> > It seems to me that waiting for 9.6 for what's arguably a bug fix is too
> > much. It's not like this is a new feature. Why don't we just make sure
> > it is as correct as possible and get it done for 9.5? It's not even in
> > be
Hi Devrim,
I will take a look at this.
regards,
Szymon
On 29 April 2015 at 18:24, Devrim Gündüz wrote:
>
> Hi,
>
> Anyone? :)
>
> Regards, Devrim
>
> On Wed, 2015-03-18 at 15:19 +0200, Devrim Gündüz wrote:
> > Hi,
> >
> > Background info first: PL/Ruby was originally maintained by Guy Decoux,
>
On Wed, Apr 29, 2015 at 3:21 PM, Jeff Janes wrote:
> On Wed, Apr 29, 2015 at 11:27 AM, Robert Haas wrote:
>> On Tue, Apr 28, 2015 at 12:47 PM, Jeff Janes wrote:
>> > This commit is causing a compiler warning for me in non-cassert builds:
>> >
>> > funcapi.c: In function 'get_func_trftypes':
>> >
On Wed, Apr 29, 2015 at 3:13 PM, Stephen Frost wrote:
> My general feeling is "keep it short" but I'm not particular beyond
> that. I do like the idea that we'll be able to support more options in
> the future.
Yeah. To me "ON CONFLICT" sounds like "if there's a war, then...".
So I like ON DUPL
On Wed, Apr 29, 2015 at 11:27 AM, Robert Haas wrote:
> On Tue, Apr 28, 2015 at 12:47 PM, Jeff Janes wrote:
> > This commit is causing a compiler warning for me in non-cassert builds:
> >
> > funcapi.c: In function 'get_func_trftypes':
> > funcapi.c:890: warning: unused variable 'procStruct'
> >
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Apr 27, 2015 at 7:21 PM, Peter Geoghegan wrote:
> > On Mon, Apr 27, 2015 at 10:20 AM, Bruce Momjian wrote:
> >> Agreed, and I like the DO [ UPDATE | NOTHING ] too.
> >
> > Here is what I think I need to do:
> >
> > * Don't change the ON CONFL
On 04/29/2015 01:19 PM, Robert Haas wrote:
On Mon, Apr 27, 2015 at 6:41 PM, Andrew Dunstan wrote:
There's one exception I, at least, have to this rule, namely when there's a
corresponding compound if or else. I personally find this unaesthetic to put
it mildly:
if (condition)
stat
On Mon, Apr 27, 2015 at 7:21 PM, Peter Geoghegan wrote:
> On Mon, Apr 27, 2015 at 10:20 AM, Bruce Momjian wrote:
>> Agreed, and I like the DO [ UPDATE | NOTHING ] too.
>
> Here is what I think I need to do:
>
> * Don't change the ON CONFLICT spelling.
What I proposed originally was ON DUPLICATE.
On 04/28/2015 04:10 PM, Andrew Dunstan wrote:
On 04/28/2015 12:03 PM, Andrew Dunstan wrote:
[switching to -hackers]
On 04/28/2015 11:51 AM, Andrew Dunstan wrote:
On 04/28/2015 09:04 AM, Michael Paquier wrote:
On Tue, Apr 28, 2015 at 10:01 AM, Michael Paquier
wrote:
On Tue, Apr 28, 2015
On Tue, Apr 28, 2015 at 12:47 PM, Jeff Janes wrote:
> This commit is causing a compiler warning for me in non-cassert builds:
>
> funcapi.c: In function 'get_func_trftypes':
> funcapi.c:890: warning: unused variable 'procStruct'
>
> Adding PG_USED_FOR_ASSERTS_ONLY seems to fix it.
I took a stab a
On Tue, Apr 28, 2015 at 3:59 PM, Tom Lane wrote:
> Robert Haas writes:
>> rhaas=# create table foo (a int);
>> CREATE TABLE
>> rhaas=# create or replace function test (x foo) returns int as $$begin
>> return x.b; end$$ language plpgsql;
>> CREATE FUNCTION
>> rhaas=# alter table foo add column b i
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Robert Haas wrote:
> > On Mon, Apr 27, 2015 at 6:41 PM, Andrew Dunstan wrote:
> > > There's one exception I, at least, have to this rule, namely when there's
> > > a
> > > corresponding compound if or else. I personally find this unaesthetic to
Robert Haas wrote:
> On Mon, Apr 27, 2015 at 6:41 PM, Andrew Dunstan wrote:
> > There's one exception I, at least, have to this rule, namely when there's a
> > corresponding compound if or else. I personally find this unaesthetic to put
> > it mildly:
> >
> >if (condition)
> >statement
>
> Really? Why? I would think it's the policy's job to restrict relabel
> operations.
>
I agree. This seems like an unnecessary change.
-Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
On Wed, Apr 29, 2015 at 9:15 AM, Denis Kirjanov wrote:
> Enforce access control on security labels defined by admin
> and prohibit users to relabel the objects
Really? Why? I would think it's the policy's job to restrict relabel
operations.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb
Enforce access control on security labels defined by admin
and prohibit users to relabel the objects
Signed-off-by: Denis Kirjanov
---
contrib/sepgsql/label.c |5 +
1 file changed, 5 insertions(+)
diff --git a/contrib/sepgsql/label.c b/contrib/sepgsql/label.c
index ef7661c..470b90e 1006
On Tue, Apr 28, 2015 at 11:32 AM, Robert Haas wrote:
> On Fri, Apr 24, 2015 at 3:04 PM, Alvaro Herrera
> wrote:
>
> > I think what we need here is something that does heap_update to tuples
> > at the end of the table, moving them to earlier pages; then wait for old
> > snapshots to die (the infr
On Mon, Apr 27, 2015 at 6:41 PM, Andrew Dunstan wrote:
> There's one exception I, at least, have to this rule, namely when there's a
> corresponding compound if or else. I personally find this unaesthetic to put
> it mildly:
>
>if (condition)
>statement;
>else
>{
>block
On Mon, Apr 27, 2015 at 5:01 PM, Jim Nasby wrote:
> The problem with just having the value is that if *anything* changes between
> how you evaluated the value when you created the index tuple and when you
> evaluate it a second time you'll corrupt your index. This is actually an
> incredibly easy
On Mon, Apr 27, 2015 at 10:59 AM, Andrew Dunstan wrote:
> Yeah. I've pushed this with tiny fixes to avoid Leaning Toothpick Syndrome
> (man perlop for definition).
I had to Google that. Then I had to think about it. Then I laughed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The
On Mon, Apr 27, 2015 at 7:47 AM, Michael Paquier
wrote:
> Authorizing ALTER FOREIGN TABLE as query string that a FDW can use
> with IMPORT FOREIGN SCHEMA is a different feature than what is
> proposed in this patch, aka an option for postgres_fdw and meritates a
> discussion on its own because it
Fabrízio de Royes Mello wrote:
> I have this idea:
>
> 1) Add an ObjectAddress field to CommentStmt struct an set it in gram.y
>
> 2) In the CommentObject check if CommentStmt->address is
> InvalidObjectAddress then call get_object_address else use it
For DDL deparsing purposes, it seems import
On Tue, Apr 28, 2015 at 2:44 PM, Alvaro Herrera
wrote:
>> > I think what we need here is something that does heap_update to tuples
>> > at the end of the table, moving them to earlier pages; then wait for old
>> > snapshots to die (the infrastructure for which we have now, thanks to
>> > CREATE IN
On Mon, Apr 27, 2015 at 2:50 AM, Etsuro Fujita
wrote:
> Here is a patch to add missing tab-completion for ALTER FOREIGN TABLE.
> I'll add this to the next CF.
Committed, thanks.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hacke
On Wed, Apr 29, 2015 at 1:14 PM, Alvaro Herrera
wrote:
>
> Fabrízio de Royes Mello wrote:
> >
> > Looking at the patch again I realize the code is very ugly, so I'll
rework
> > the patch.
>
> Yes, I think get_object_address should figure out what to do with the
> representation of CURRENT DATABASE
On 2015-04-28 10:26:54 +0530, Abhijit Menon-Sen wrote:
> Hi Andres. Do you intend to commit these patches? (I just verified that
> they apply without trouble to HEAD.)
I intend to come back to them, yes. I'm not fully sure whether we should
really apply them to the back branches.
Greetings,
Andr
On 04/29/15 18:26, Tom Lane wrote:
Tomas Vondra writes:
...
OK, let me explain the context a bit more. When working on the
multivariate statistics patch, I need to choose which stats to use for
estimating the clauses. I do that in clauselist_selectivity(), although
there might be other places
Tomas Vondra writes:
> On 04/29/15 05:55, Tom Lane wrote:
>> pull_varnos is not, and should not be, applied to a RestrictInfo; for one
>> thing, it'd be redundant with work that was already done when creating the
>> RestrictInfo (cf make_restrictinfo_internal). You've not shown the
>> context of
Hi,
Anyone? :)
Regards, Devrim
On Wed, 2015-03-18 at 15:19 +0200, Devrim Gündüz wrote:
> Hi,
>
> Background info first: PL/Ruby was originally maintained by Guy Decoux,
> who passed away in 2008: https://www.ruby-forum.com/topic/166658 . After
> his death, Akinori MUSHA forked the project and
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
Looks good - ready for committer.
The new status of this pat
Fabrízio de Royes Mello wrote:
>
> Looking at the patch again I realize the code is very ugly, so I'll rework
> the patch.
Yes, I think get_object_address should figure out what to do with the
representation of CURRENT DATABASE directly, rather than having the
COMMENT code morph from that into a
Hi,
On 04/29/15 05:55, Tom Lane wrote:
Tomas Vondra writes:
On 04/28/15 21:50, Tom Lane wrote:
RestrictInfo is not a general expression node and support for it has
been deliberately omitted from expression_tree_walker(). So I think
what you are proposing is a bad idea and probably a band-aid
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> For the specific cases you mention, perhaps it would be all right if we
>> taught plancache.c to blow away *all* cached plans upon seeing any change
>> in pg_operator; but that seems like a brute-force solution.
> Agreed that it is
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Alexander Korotkov writes:
> > My proposal is to let ALTER OPERATOR change restrict and join selectivity
> > functions of the operator. Also it would be useful to be able to change
> > commutator and negator of operator: extension could add commutators and
Oleg Bartunov writes:
> Any chance to have this patch in 9.5 ? Many intarray users will be happy.
Considering how desperately behind we are on reviewing/committing patches
that were submitted by the deadline, I don't think it would be appropriate
or fair to add on major new patches that came in m
Alexander Korotkov writes:
> My proposal is to let ALTER OPERATOR change restrict and join selectivity
> functions of the operator. Also it would be useful to be able to change
> commutator and negator of operator: extension could add commutators and
> negators in further versions. Any thoughts?
Robert, all,
* Stephen Frost (sfr...@snowman.net) wrote:
> * Stephen Frost (sfr...@snowman.net) wrote:
> > * Robert Haas (robertmh...@gmail.com) wrote:
> > > The tricky part of this seems to me to be the pg_dump changes. The
> > > new catalog flag seems a little sketchy to me; wouldn't it be bett
Heikki,
* Heikki Linnakangas (hlinn...@iki.fi) wrote:
> The problem seems to be that when the standby is promoted, it's a
> so-called "fast promotion", where it writes an end-of-recovery
> record and starts accepting queries before creating a real
> checkpoint. pg_rewind looks at the TLI in the la
Any chance to have this patch in 9.5 ? Many intarray users will be happy.
On Wed, Apr 29, 2015 at 1:48 PM, Alexander Korotkov
wrote:
> Hackers,
>
> currently built-in &&, @>, <@ array operators have selectivity estimations
> while same operator in intarray contrib haven't them. Problem is that
>
On Wed, Apr 29, 2015 at 12:48 PM, Tom Lane wrote:
> Peter Eisentraut writes:
>> On 4/28/15 12:05 AM, Tom Lane wrote:
>>> Yeah. Even more specifically, olinguito does have --with-python in its
>>> configure flags, but then the plpython Makefile skips the build because
>>> libpython isn't availabl
Hackers,
currently built-in &&, @>, <@ array operators have selectivity estimations
while same operator in intarray contrib haven't them. Problem is that
operators in intarray contrib still use contsel and contjoinsel functions
for selectivity estimation even when built-in operators receive their
On Wed, Apr 29, 2015 at 12:20 AM, David Steele wrote:
> On 4/27/15 10:37 PM, Sawada Masahiko wrote:
>>
>> Thank you for your reviewing.
>> Attached v8 patch is latest version.
>
> I posted a review through the CF app but it only went to the list
> instead of recipients of the latest message. inst
Hi all
I am looking on this patch. I can confirm 10-15% speedup - and the idea
behind this patch looks well.
This patch
http://www.postgresql.org/message-id/4146.1425872...@sss.pgh.pa.us contains
two parts
a) relative large refactoring
b) support for resettable fields in param_list instead tota
83 matches
Mail list logo
