2015-11-05 7:39 GMT+01:00 Craig Ringer :
> On 5 November 2015 at 05:22, Pavel Stehule
> wrote:
>
> > If I understand to text on wiki, the name is used for tool, that can do
> > little bit more things, but it is often used for this technique (so it is
> > much better than "rotate"). I don't unders
On 5 November 2015 at 05:22, Pavel Stehule wrote:
> If I understand to text on wiki, the name is used for tool, that can do
> little bit more things, but it is often used for this technique (so it is
> much better than "rotate"). I don't understand well, why "crosstab" is too
> wrong name. This i
Hi
I had talk about possibility to implement PL/SQL packages in Postgres.
The package concept is coming from ADA language and it is partially
foreign/redundant element in SQL world. Oracle needs it for modularization,
because schema plays different role there than in Postgres. My opinion
about pa
On Wed, Nov 4, 2015 at 10:12 AM, Pavel Stehule wrote:
> It helped me lot of, thank you
Welcome, I learned quite some from the process as well.
>>
>>
>> There's just the doc part left then.
>
>
> done
We're almost there but not quite.
There's still a typo in the docs: excation.
A plpy.SPIError
On Wed, Nov 4, 2015 at 7:33 PM, Andres Freund wrote:
> On 2015-11-04 16:01:28 +0900, Michael Paquier wrote:
>> On Wed, Nov 4, 2015 at 8:39 AM, Andres Freund wrote:
>> > On November 4, 2015 12:37:02 AM GMT+01:00, Michael Paquier wrote:
>> >>On a completely idle system, I don't think we should log
On Tue, Nov 3, 2015 at 9:41 PM, Amit Kapila wrote:
> On Fri, Oct 23, 2015 at 4:41 PM, Amit Kapila
> wrote:
>>
>> On Fri, Oct 23, 2015 at 10:33 AM, Robert Haas
>> wrote:
>
> Please find the rebased partial seq scan patch attached with this
> mail.
>
> Robert suggested me off list that we should o
On Sat, Aug 29, 2015 at 12:55 PM, Thomas Munro
wrote:
> On Sat, Aug 29, 2015 at 9:03 AM, Thomas Munro
> wrote:
>>
>> On Fri, Aug 28, 2015 at 10:30 PM, jacques klein
>> wrote:
>>>
>>> Hello,
>>>
>>> I added a "NOFITY chan" to the SQL arg of an SPI_execute(), (I did it
>>> also with just the NOTIF
On Thu, Nov 5, 2015 at 1:16 PM, Tom Lane wrote:
> Michael Paquier writes:
>> On Thu, Nov 5, 2015 at 12:17 PM, Peter Eisentraut wrote:
>>> That might be worth a try. I ended up disabling system integrity
>>> protection, which also fixed a few other strange behaviors (mysterious
>>> regression te
Michael Paquier writes:
> On Thu, Nov 5, 2015 at 12:17 PM, Peter Eisentraut wrote:
>> That might be worth a try. I ended up disabling system integrity
>> protection, which also fixed a few other strange behaviors (mysterious
>> regression test failures in ecpg, for instance, if anyone stumbles
>
On Thu, Nov 5, 2015 at 12:17 PM, Peter Eisentraut wrote:
> On 11/3/15 6:36 AM, Andres Freund wrote:
>> I wonder if we could fix this by using install_name_tool during the
>> tempinstall to add an appropriate rpath.
>>
>> Alternatively we could, apparently, specify a relative path to libraries
>> a
On 11/3/15 6:36 AM, Andres Freund wrote:
> I wonder if we could fix this by using install_name_tool during the
> tempinstall to add an appropriate rpath.
>
> Alternatively we could, apparently, specify a relative path to libraries
> as explained here:
> http://qin.laya.com/tech_coding_help/dylib_l
On 5 November 2015 at 13:20, Peter Geoghegan wrote:
> On Fri, Sep 11, 2015 at 9:00 AM, David Rowley
> wrote:
> > Attached is also timestamp_delta.patch which changes pg_ltostr() to use
> the
> > INT_MIN special case that pg_ltoa also uses. I didn't make a similar
> change
> > to pg_ltostr_zeropa
Hi,
On 11/04/2015 11:32 PM, Tom Lane wrote:
Jeff Janes writes:
On Wed, Nov 4, 2015 at 7:14 AM, Tom Lane wrote:
You're missing my point: that is possible in an indexscan, but
*not* in a bitmap indexscan, because the index AM APIs are
totally different in the two cases. In a bitmap scan, nothi
On Wed, Nov 04, 2015 at 08:20:28AM -0800, Joe Conway wrote:
> On 11/04/2015 04:09 AM, Pavel Stehule wrote:
> > I am looking on this last patch. I talked about the name of this command
> > with more people, and the name "rotate" is unhappy. The correct name for
> > this visualization technique is "c
> -Original Message-
> From: Kyotaro HORIGUCHI [mailto:horiguchi.kyot...@lab.ntt.co.jp]
> Sent: Thursday, November 05, 2015 10:02 AM
> To: fujita.ets...@lab.ntt.co.jp
> Cc: Kaigai Kouhei(海外 浩平); robertmh...@gmail.com; t...@sss.pgh.pa.us;
> pgsql-hackers@postgresql.org; shigeru.han...@gmail.
Hi, I've caught up again.
> OK, so if we all agree that the joined-tuple optimization is just an
> option for the case where all the component tables use ROW_MARK_COPY,
> I'd propose to leave that for 9.6.
I still think that ExecScan is called under EPQ recheck without
EQP tuple for the *scan*.
On Fri, Sep 11, 2015 at 9:00 AM, David Rowley
wrote:
> Attached is also timestamp_delta.patch which changes pg_ltostr() to use the
> INT_MIN special case that pg_ltoa also uses. I didn't make a similar change
> to pg_ltostr_zeropad() as I'd need to add even more special code to prepend
> the corre
On 11/04/2015 02:53 PM, Stephen Frost wrote:
This implies that a statement used takes a long time. It may not. The
lock is held at the transaction level not the statement level, which is
why a transaction level timeout is actually more useful than a statement
level timeout.
What I'm most intere
2015-11-05 0:07 GMT+01:00 Daniel Verite :
> Pavel Stehule wrote:
>
> > I am looking on this last patch. I talked about the name of this command
> > with more people, and the name "rotate" is unhappy. The correct name for
> > this visualization technique is "crosstab" (see google "crosstab"
Joe Conway wrote:
> but if you don't want to conflict with the name
> crosstab, perhaps "pivot" would be better?
Initially I had chosen \pivot without much thought about it,
but the objection was raised that a PIVOT/UNPIVOT SQL feature
would likely exist in core in a next release independ
Pavel Stehule wrote:
> I am looking on this last patch. I talked about the name of this command
> with more people, and the name "rotate" is unhappy. The correct name for
> this visualization technique is "crosstab" (see google "crosstab"). The
> conflict with our extension is unhappy, but
2015-11-04 23:53 GMT+01:00 Stephen Frost :
> JD,
>
> On Wednesday, November 4, 2015, Joshua D. Drake
> wrote:
>
>> On 11/04/2015 02:15 PM, Stephen Frost wrote:
>>
>> Yeah but anything holding a lock that long can be terminated via
statement_timeout can it not?
>>>
>>> Well, no? stateme
JD,
On Wednesday, November 4, 2015, Joshua D. Drake
wrote:
> On 11/04/2015 02:15 PM, Stephen Frost wrote:
>
> Yeah but anything holding a lock that long can be terminated via
>>> statement_timeout can it not?
>>>
>>
>> Well, no? statement_timeout is per-statement, while transaction_timeout
>> i
On 10/30/2015 10:20 PM, Merlin Moncure wrote:
> Idle hanging transactions from poorly written applications are the
> bane of my existence. Several months back one of them took down one
> of hour production websites for several hours.
>
> Unfortunately, the only way to deal with them is to termina
Jeff Janes writes:
> On Wed, Nov 4, 2015 at 7:14 AM, Tom Lane wrote:
>> You're missing my point: that is possible in an indexscan, but *not* in a
>> bitmap indexscan, because the index AM APIs are totally different in the
>> two cases. In a bitmap scan, nothing more than a TID bitmap is ever
>>
On 11/04/2015 02:15 PM, Stephen Frost wrote:
Yeah but anything holding a lock that long can be terminated via
statement_timeout can it not?
Well, no? statement_timeout is per-statement, while transaction_timeout
is, well, per transaction. If there's a process which is going and has
an open t
* Joshua D. Drake (j...@commandprompt.com) wrote:
> On 11/04/2015 01:55 PM, Stephen Frost wrote:
> >* Joe Conway (m...@joeconway.com) wrote:
> >>On 11/04/2015 01:24 PM, Alvaro Herrera wrote:
> >>>I agree with Pavel. Having a transaction timeout just does not make any
> >>>sense. I can see absolut
On 11/04/2015 02:07 PM, Joshua D. Drake wrote:
> On 11/04/2015 01:55 PM, Stephen Frost wrote:
>> * Joe Conway (m...@joeconway.com) wrote:
>>> On 11/04/2015 01:24 PM, Alvaro Herrera wrote:
I agree with Pavel. Having a transaction timeout just does not make
any
sense. I can see absol
Alvaro Herrera writes:
> Tom Lane wrote:
>> Having said that, though, I believe that it's also probably a
>> *different* initial shuffle, which may well mean that GEQO gives
>> different plans in some cases. That doesn't bother me as long as
>> we only make the change in HEAD, but does anyone wan
On 11/04/2015 01:55 PM, Stephen Frost wrote:
> * Joe Conway (m...@joeconway.com) wrote:
>> On 11/04/2015 01:24 PM, Alvaro Herrera wrote:
>>> I agree with Pavel. Having a transaction timeout just does not make any
>>> sense. I can see absolutely no use for it. An idle-in-transaction
>>> timeout,
On 11/04/2015 01:55 PM, Stephen Frost wrote:
* Joe Conway (m...@joeconway.com) wrote:
On 11/04/2015 01:24 PM, Alvaro Herrera wrote:
I agree with Pavel. Having a transaction timeout just does not make any
sense. I can see absolutely no use for it. An idle-in-transaction
timeout, on the other
* Joe Conway (m...@joeconway.com) wrote:
> On 11/04/2015 01:24 PM, Alvaro Herrera wrote:
> > I agree with Pavel. Having a transaction timeout just does not make any
> > sense. I can see absolutely no use for it. An idle-in-transaction
> > timeout, on the other hand, is very useful.
>
> +1 -- ag
On 11/04/2015 01:24 PM, Alvaro Herrera wrote:
> I agree with Pavel. Having a transaction timeout just does not make any
> sense. I can see absolutely no use for it. An idle-in-transaction
> timeout, on the other hand, is very useful.
+1 -- agreed
Joe
--
Crunchy Data - http://crunchydata.com
Pavel Stehule wrote:
> 2015-11-04 22:14 GMT+01:00 Joshua D. Drake :
>
> > On 11/04/2015 01:11 PM, Pavel Stehule wrote:
> >
> >> I am sorry, but I have a different experience from GoodData. The few
> >> hours autovacuum is usual. So probably, there should be exception for
> >> autovacuum, dump, ..
2015-11-04 17:20 GMT+01:00 Joe Conway :
> On 11/04/2015 04:09 AM, Pavel Stehule wrote:
> > I am looking on this last patch. I talked about the name of this command
> > with more people, and the name "rotate" is unhappy. The correct name for
> > this visualization technique is "crosstab" (see googl
2015-11-04 21:31 GMT+01:00 Merlin Moncure :
> On Wed, Nov 4, 2015 at 2:09 PM, Pavel Stehule
> wrote:
> > 2015-11-04 20:35 GMT+01:00 Merlin Moncure :
> >>
> >> On Wed, Nov 4, 2015 at 11:26 AM, Pavel Stehule >
>
> >> > it doesn't help. How I can set transaction_timeout if I have series of
> >> > s
2015-11-04 22:14 GMT+01:00 Joshua D. Drake :
> On 11/04/2015 01:11 PM, Pavel Stehule wrote:
>
>
>> I am sorry, but I have a different experience from GoodData. The few
>> hours autovacuum is usual. So probably, there should be exception for
>> autovacuum, dump, ..
>>
>
> But autovacuum and dump ar
On 11/04/2015 01:11 PM, Pavel Stehule wrote:
I am sorry, but I have a different experience from GoodData. The few
hours autovacuum is usual. So probably, there should be exception for
autovacuum, dump, ..
But autovacuum and dump are not idle in transaction or am I missing
something?
JD
--
2015-11-04 21:56 GMT+01:00 Joshua D. Drake :
> On 11/04/2015 12:31 PM, Merlin Moncure wrote:
>
> My issue isn't long statements, but broken client, that is broken in wrong
>>> state - connect is still active, but no any statement will coming.
>>>
>>
>> Right, 'Idle in transaction'. Agree that a s
On 11/04/2015 12:31 PM, Merlin Moncure wrote:
My issue isn't long statements, but broken client, that is broken in wrong
state - connect is still active, but no any statement will coming.
Right, 'Idle in transaction'. Agree that a setting directed purely at
that problem could set a much lower
On Wed, Nov 4, 2015 at 2:09 PM, Pavel Stehule wrote:
> 2015-11-04 20:35 GMT+01:00 Merlin Moncure :
>>
>> On Wed, Nov 4, 2015 at 11:26 AM, Pavel Stehule
>> > it doesn't help. How I can set transaction_timeout if I have series of
>> > slow
>> > statements? In this case I cannot to set transaction_
2015-11-04 20:35 GMT+01:00 Merlin Moncure :
> On Wed, Nov 4, 2015 at 11:26 AM, Pavel Stehule
> wrote:
> > 2015-11-04 18:18 GMT+01:00 Merlin Moncure :
> >>
> >> On Wed, Nov 4, 2015 at 11:15 AM, Pavel Stehule >
> >> wrote:
> >> >
> >> >
> >> > 2015-11-04 18:11 GMT+01:00 Tom Lane :
> >> >>
> >> >>
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Nov 4, 2015 at 1:48 PM, Stephen Frost wrote:
> > * Robert Haas (robertmh...@gmail.com) wrote:
> >> FORCE ROW LEVEL SECURITY doesn't behave as I would expect.
> >>
> >> rhaas=# create policy hideit on foo1 using (a < 3);
> >> CREATE PO
On Wed, Nov 4, 2015 at 1:48 PM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> FORCE ROW LEVEL SECURITY doesn't behave as I would expect.
>>
>> rhaas=# create policy hideit on foo1 using (a < 3);
>> CREATE POLICY
>> rhaas=# explain select * from foo1;
>>
On Wed, Nov 4, 2015 at 11:26 AM, Pavel Stehule wrote:
> 2015-11-04 18:18 GMT+01:00 Merlin Moncure :
>>
>> On Wed, Nov 4, 2015 at 11:15 AM, Pavel Stehule
>> wrote:
>> >
>> >
>> > 2015-11-04 18:11 GMT+01:00 Tom Lane :
>> >>
>> >> Merlin Moncure writes:
>> >> >> Yes, and that is what I meant. I ha
* Robert Haas (robertmh...@gmail.com) wrote:
> FORCE ROW LEVEL SECURITY doesn't behave as I would expect.
>
> rhaas=# create policy hideit on foo1 using (a < 3);
> CREATE POLICY
> rhaas=# explain select * from foo1;
>QUERY PLAN
>
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> FORCE ROW LEVEL SECURITY doesn't behave as I would expect.
>
> rhaas=# create policy hideit on foo1 using (a < 3);
> CREATE POLICY
> rhaas=# explain select * from foo1;
>QUERY PLAN
> ---
FORCE ROW LEVEL SECURITY doesn't behave as I would expect.
rhaas=# create policy hideit on foo1 using (a < 3);
CREATE POLICY
rhaas=# explain select * from foo1;
QUERY PLAN
-
Seq Scan on foo1 (cost=0.00..22.70 rows=127
Tom Lane wrote:
> Having said that, though, I believe that it's also probably a
> *different* initial shuffle, which may well mean that GEQO gives
> different plans in some cases. That doesn't bother me as long as
> we only make the change in HEAD, but does anyone want to complain?
Uh, do we pro
On Wed, Nov 4, 2015 at 7:14 AM, Tom Lane wrote:
> Simon Riggs writes:
>> On 4 November 2015 at 15:54, Tom Lane wrote:
>> We generate this plan
>> Index Scan using f_x_y_idx on f (cost=0.42..26075.71 rows=209 width=37)
>>Index Cond: (x = 5)
>>Filter: (y ~~ '%abc%'::text)
>
>> So it shou
On Wed, Nov 4, 2015 at 10:59 AM, Tom Lane wrote:
> Simon Riggs writes:
>> On 4 November 2015 at 16:14, Tom Lane wrote:
>>> You're missing my point: that is possible in an indexscan, but *not* in a
>>> bitmap indexscan, because the index AM APIs are totally different in the
>>> two cases. In a b
On Tue, Nov 3, 2015 at 6:40 PM, Michael Paquier
wrote:
> On Wed, Nov 4, 2015 at 2:31 AM, Robert Haas wrote:
>> On Tue, Nov 3, 2015 at 8:31 AM, Alvaro Herrera
>> wrote:
>>> (WRT the reference to Jane Austen and "Se'ennight" for "week", it occurs
>>> to me that fortnight is a similar contraction
Nathan Wagner writes:
> I have two patches to make the geqo initialization and mutation
> slightly better.
> The first adjusts the mutation swaps to avoid having to re-pick
> ties. The second changes the initialization and shuffling algorithm
> for the gene array to use an in-place Fisher-Yates
On 4 November 2015 at 16:59, Tom Lane wrote:
> Simon Riggs writes:
> > On 4 November 2015 at 16:14, Tom Lane wrote:
> >> You're missing my point: that is possible in an indexscan, but *not* in
> a
> >> bitmap indexscan, because the index AM APIs are totally different in the
> >> two cases. In
2015-11-04 18:18 GMT+01:00 Merlin Moncure :
> On Wed, Nov 4, 2015 at 11:15 AM, Pavel Stehule
> wrote:
> >
> >
> > 2015-11-04 18:11 GMT+01:00 Tom Lane :
> >>
> >> Merlin Moncure writes:
> >> >> Yes, and that is what I meant. I have two problems with
> >> >> transaction_idle_timeout (as opposed t
On Wed, Nov 4, 2015 at 11:15 AM, Pavel Stehule wrote:
>
>
> 2015-11-04 18:11 GMT+01:00 Tom Lane :
>>
>> Merlin Moncure writes:
>> >> Yes, and that is what I meant. I have two problems with
>> >> transaction_idle_timeout (as opposed to transaction_timeout):
>> >>
>> >> A) It's more complex. Unso
2015-11-04 18:11 GMT+01:00 Tom Lane :
> Merlin Moncure writes:
> >> Yes, and that is what I meant. I have two problems with
> >> transaction_idle_timeout (as opposed to transaction_timeout):
> >>
> >> A) It's more complex. Unsophisticated administrators may not
> >> understand or set it properl
Merlin Moncure writes:
>> Yes, and that is what I meant. I have two problems with
>> transaction_idle_timeout (as opposed to transaction_timeout):
>>
>> A) It's more complex. Unsophisticated administrators may not
>> understand or set it properly
>>
>> B) There is no way to enforce an upper bo
On 11/04/2015 04:09 AM, Pavel Stehule wrote:
> I am looking on this last patch. I talked about the name of this command
> with more people, and the name "rotate" is unhappy. The correct name for
> this visualization technique is "crosstab" (see google "crosstab"). The
> conflict with our extension
2015-11-04 17:02 GMT+01:00 Merlin Moncure :
> On Wed, Nov 4, 2015 at 8:54 AM, Pavel Stehule
> wrote:
> > 2015-11-04 15:50 GMT+01:00 Merlin Moncure :
> >>
> >> On Wed, Nov 4, 2015 at 8:42 AM, Pavel Stehule
> >> wrote:
> >> >> > Okay, I think one more point to consider is that it would be
> >> >>
On Wed, Nov 4, 2015 at 10:02 AM, Merlin Moncure wrote:
> On Wed, Nov 4, 2015 at 8:54 AM, Pavel Stehule wrote:
>> 2015-11-04 15:50 GMT+01:00 Merlin Moncure :
>>>
>>> On Wed, Nov 4, 2015 at 8:42 AM, Pavel Stehule
>>> wrote:
>>> >> > Okay, I think one more point to consider is that it would be
>>>
On Wed, Nov 4, 2015 at 8:54 AM, Pavel Stehule wrote:
> 2015-11-04 15:50 GMT+01:00 Merlin Moncure :
>>
>> On Wed, Nov 4, 2015 at 8:42 AM, Pavel Stehule
>> wrote:
>> >> > Okay, I think one more point to consider is that it would be
>> >> > preferable
>> >> > to
>> >> > have such an option for backe
Simon Riggs writes:
> On 4 November 2015 at 16:14, Tom Lane wrote:
>> You're missing my point: that is possible in an indexscan, but *not* in a
>> bitmap indexscan, because the index AM APIs are totally different in the
>> two cases. In a bitmap scan, nothing more than a TID bitmap is ever
>> re
On 4 November 2015 at 16:14, Tom Lane wrote:
> Simon Riggs writes:
> > On 4 November 2015 at 15:54, Tom Lane wrote:
> > We generate this plan
> > Index Scan using f_x_y_idx on f (cost=0.42..26075.71 rows=209 width=37)
> >Index Cond: (x = 5)
> >Filter: (y ~~ '%abc%'::text)
>
> > So it
Hello Alvaro,
For instance for "random_gaussian(int, int, double)", it may be called with
any combination of 3 int/double arguments, each one must be tested and
possibly converted to the target type before calling the actual function.
For overloaded operators or functions (arithmetics, abs...)
Simon Riggs writes:
> On 4 November 2015 at 15:54, Tom Lane wrote:
> We generate this plan
> Index Scan using f_x_y_idx on f (cost=0.42..26075.71 rows=209 width=37)
>Index Cond: (x = 5)
>Filter: (y ~~ '%abc%'::text)
> So it should be possible to do the Filter condition on the BitmapInd
Fabien COELHO wrote:
> For instance for "random_gaussian(int, int, double)", it may be called with
> any combination of 3 int/double arguments, each one must be tested and
> possibly converted to the target type before calling the actual function.
> For overloaded operators or functions (arithmeti
> > On Tue, Sep 29, 2015 at 6:19 PM, Kouhei Kaigai wrote:
> > >> On Mon, Sep 28, 2015 at 8:31 PM, Kouhei Kaigai
> > >> wrote:
> > >> >> Instead of doing this:
> > >> >>
> > >> >> +/* Dump library and symbol name instead of raw pointer */
> > >> >> appendStringInfoString(str, " :methods
On 4 November 2015 at 15:54, Tom Lane wrote:
> Nicolas Barbier writes:
> > 2015-11-04 Antonin Houska :
> >> (see expand_indexqual_opclause()), I'm not sure any kind of expansion is
> >> possible for '%abc%' which would result in a b-tree searchable
> condition.
>
> > I think the question is not
2015-11-04 15:50 GMT+01:00 Merlin Moncure :
> On Wed, Nov 4, 2015 at 8:42 AM, Pavel Stehule
> wrote:
> >> > Okay, I think one more point to consider is that it would be
> preferable
> >> > to
> >> > have such an option for backend sessions and not for other processes
> >> > like WalSender.
> >>
>
Nicolas Barbier writes:
> 2015-11-04 Antonin Houska :
>> (see expand_indexqual_opclause()), I'm not sure any kind of expansion is
>> possible for '%abc%' which would result in a b-tree searchable condition.
> I think the question is not about using the b-tree for checking the
> condition, but abo
On Wed, Nov 4, 2015 at 8:42 AM, Pavel Stehule wrote:
>> > Okay, I think one more point to consider is that it would be preferable
>> > to
>> > have such an option for backend sessions and not for other processes
>> > like WalSender.
>>
>> All right...I see the usage.. I withdraw my objection to '
> Okay, I think one more point to consider is that it would be preferable to
> > have such an option for backend sessions and not for other processes
> > like WalSender.
>
> All right...I see the usage.. I withdraw my objection to 'session'
> prefix then now that I understand the case. So, do you
On Wed, Nov 4, 2015 at 8:06 PM, Merlin Moncure wrote:
>
> On Tue, Nov 3, 2015 at 10:33 PM, Amit Kapila
wrote:
> It is 100% true. But the users can do strange things. If we solve
idle
> transactions and not idle session, then they are able to increase
> max_connections to thousands
On 4 November 2015 at 20:48, Bill Moran wrote:
> On a related note, since I've been digging in this area of code I feel
> comfortable commenting that pluggable compression isn't terribly difficult
> to implement. The most significant work will probably be in actually
> implementing the various al
On Tue, Nov 3, 2015 at 10:33 PM, Amit Kapila wrote:
> On Tue, Nov 3, 2015 at 7:56 PM, Pavel Stehule
> wrote:
>>
>>
>>
>> 2015-11-03 3:42 GMT+01:00 Amit Kapila :
>>>
>>> On Mon, Nov 2, 2015 at 10:45 PM, Pavel Stehule
>>> wrote:
It is 100% true. But the users can do strange things.
[BCC to pgsql-cluster-hack...@postgresql.org]
I have summarized the Vienna cluster summit meeting from last week by
adding italicized answers to the agenda questions, even though we didn't
follow the agenda ;-) :
https://wiki.postgresql.org/wiki/PG-EU_2015_Cluster_Summit
I would like to
Peter Geoghegan wrote:
> On Mon, Jul 27, 2015 at 7:12 AM, Alvaro Herrera
> wrote:
> > I only tried a few tests, for lack of time, and it didn't produce any.
> > (To verify that the whole thing was working properly, I reduced the
> > range of memory made available during PinBuffer and that resulted
On Wed, 4 Nov 2015 13:07:09 +0800
Craig Ringer wrote:
> On 4 November 2015 at 10:58, Bill Moran wrote:
> > On Tue, 3 Nov 2015 18:34:39 -0800
> > Jeff Janes wrote:
> >
> >> On Tue, Nov 3, 2015 at 5:21 PM, Craig Ringer wrote:
> >> > On 3 November 2015 at 23:04, Bill Moran wrote:
> >> >>
> >> >>
Hi
I am looking on this last patch. I talked about the name of this command
with more people, and the name "rotate" is unhappy. The correct name for
this visualization technique is "crosstab" (see google "crosstab"). The
conflict with our extension is unhappy, but using "rotate" is more worst -
(s
2015-11-04 Antonin Houska :
> While prefix expression
>
> y like 'abc%'
>
> can be converted to
>
> y >= 'abc'
>
> (see expand_indexqual_opclause()), I'm not sure any kind of expansion is
> possible for '%abc%' which would result in a b-tree searchable condition.
I think the question is not about
On 2015-11-04 16:01:28 +0900, Michael Paquier wrote:
> On Wed, Nov 4, 2015 at 8:39 AM, Andres Freund wrote:
> > On November 4, 2015 12:37:02 AM GMT+01:00, Michael Paquier wrote:
> >>On a completely idle system, I don't think we should log any standby
> >>records. This is what ~9.3 does.
> >
> > Ar
On 2015/11/04 17:28, Kouhei Kaigai wrote:
I think we need to consider a general solution that can be applied not
only to the case where the component tables in a foreign join all use
ROW_MARK_COPY but to the case where those tables use different rowmark
types such as ROW_MARK_COPY and ROW_MARK_EX
On 2015/11/04 17:10, Kouhei Kaigai wrote:
On 2015/10/28 6:04, Robert Haas wrote:
On Tue, Oct 20, 2015 at 12:39 PM, Etsuro Fujita
wrote:
Sorry, my explanation was not correct. (Needed to take in caffeine.) What
I'm concerned about is the following:
SELECT * FROM localtab JOIN (ft1 LEFT JOIN f
Hi
2015-11-04 7:06 GMT+01:00 Catalin Iacob :
> Sorry, you're right, I didn't notice the x = plpy.SPIError() test.
>
> I did notice that you included the kw != NULL, I was explaining why it
> really is needed even though it *seems* the code also works without
>
it.
>
It helped me lot of, thank yo
While prefix expression
y like 'abc%'
can be converted to
y >= 'abc'
(see expand_indexqual_opclause()), I'm not sure any kind of expansion is
possible for '%abc%' which would result in a b-tree searchable condition.
Jeff Janes wrote:
> Is there a fundamental reason the filter on y is not bei
Hello Kyotaro-san,
[...] I understood the situation and agreed for current shape of the
code. I no longer object the calling-alternatively code. But I'd like
see the abbreviated discussion in the comment on the function.
Indeed, this design choice deserves much better explanations.
--
Fabie
Hello Robert,
1. I think there should really be two patches here, the first adding
functions, and the second adding doubles. Those seem like separate
changes. And offhand, the double stuff looks a lot less useful that
the function call syntax.
I first submitted the infrastructure part, but
> -Original Message-
> From: Etsuro Fujita [mailto:fujita.ets...@lab.ntt.co.jp]
> Sent: Wednesday, November 04, 2015 5:11 PM
> To: Kaigai Kouhei(海外 浩平); Robert Haas
> Cc: Tom Lane; Kyotaro HORIGUCHI; pgsql-hackers@postgresql.org; Shigeru Hanada
> Subject: Re: [HACKERS] Foreign join pushdown
Hello, I found that a typo(?) in tab-complete.c.
> /* ALTER TABLE,INDEX,MATERIALIZED VIEW xxx ALL IN TABLESPACE xxx OWNED BY */
> else if (pg_strcasecmp(prev6_wd, "ALL") == 0 &&
>pg_strcasecmp(prev5_wd, "IN") == 0 &&
>pg_strcasecmp(prev4_wd, "TABLESPACE") == 0 &&
>
On 2015/11/03 22:15, Kouhei Kaigai wrote:
A challenge is that junk wholerow references on behalf of ROW_MARK_COPY
are injected by preprocess_targetlist(). It is earlier than the main path
consideration by query_planner(), thus, it is not predictable how remote
query shall be executed at this poin
> On 2015/10/28 6:04, Robert Haas wrote:
> > On Tue, Oct 20, 2015 at 12:39 PM, Etsuro Fujita
> > wrote:
> >> Sorry, my explanation was not correct. (Needed to take in caffeine.) What
> >> I'm concerned about is the following:
> >>
> >> SELECT * FROM localtab JOIN (ft1 LEFT JOIN ft2 ON ft1.x = ft2
92 matches
Mail list logo
