On Thu, Sep 24, 2015 at 12:30 AM, Tom Lane wrote:
> Alvaro Herrera writes:
> > Tom Lane wrote:
> >> Personally I think Alvaro's position is unduly conservative: to the
> extent
> >> that plans change it'd likely be for the better. But I'm not excited
> >> enough to fight hard about it.
>
> > I
Alvaro Herrera writes:
> Tom Lane wrote:
>> Personally I think Alvaro's position is unduly conservative: to the extent
>> that plans change it'd likely be for the better. But I'm not excited
>> enough to fight hard about it.
> I don't really care enough. We have received some complaints about
>
On Wed, Sep 23, 2015 at 3:21 PM, Tom Lane wrote:
> "Shulgin, Oleksandr" writes:
> > On Tue, Sep 22, 2015 at 11:56 PM, Alvaro Herrera <
> alvhe...@2ndquadrant.com>
> > wrote:
> >> It looks like a bug to me, but I think it might destabilize approved
> >> execution plans(*), so it may not be such a
Tom Lane wrote:
> Personally I think Alvaro's position is unduly conservative: to the extent
> that plans change it'd likely be for the better. But I'm not excited
> enough to fight hard about it.
I don't really care enough. We have received some complaints about
keeping plans stable, but maybe
"Shulgin, Oleksandr" writes:
> On Tue, Sep 22, 2015 at 11:56 PM, Alvaro Herrera
> wrote:
>> It looks like a bug to me, but I think it might destabilize approved
>> execution plans(*), so it may not be such a great idea to back patch
>> branches that are already released. I think HEAD + 9.5 is go
On Tue, Sep 22, 2015 at 11:43 PM, Tom Lane wrote:
> Alvaro Herrera writes:
> > In any case I think your patch is a good starting point.
>
> The comments seemed to need some wordsmithing, but I think this is
> probably basically a good idea; we've had similar complaints before
> about some other
On Tue, Sep 22, 2015 at 11:56 PM, Alvaro Herrera
wrote:
> Tom Lane wrote:
>
> > Should we consider this HEAD-only, or a back-patchable bug fix?
> > Or perhaps compromise on HEAD + 9.5?
>
> It looks like a bug to me, but I think it might destabilize approved
> execution plans(*), so it may not be
On Tue, Sep 22, 2015 at 11:17 PM, Alvaro Herrera
wrote:
> Shulgin, Oleksandr wrote:
> > On Sep 22, 2015 8:58 PM, "Andrew Dunstan" wrote:
>
> > > Yes, "/revenons/ à /nos moutons/." You can set up text based comparison
> > > ops fairly easily for json - you just need to be aware of the
> limitatio
Tom Lane wrote:
> Should we consider this HEAD-only, or a back-patchable bug fix?
> Or perhaps compromise on HEAD + 9.5?
It looks like a bug to me, but I think it might destabilize approved
execution plans(*), so it may not be such a great idea to back patch
branches that are already released. I
Alvaro Herrera writes:
> In any case I think your patch is a good starting point.
The comments seemed to need some wordsmithing, but I think this is
probably basically a good idea; we've had similar complaints before
about some other equality-less datatypes, such as point.
Should we consider thi
Shulgin, Oleksandr wrote:
> On Sep 22, 2015 8:58 PM, "Andrew Dunstan" wrote:
> > Yes, "/revenons/ à /nos moutons/." You can set up text based comparison
> > ops fairly easily for json - you just need to be aware of the limitations.
> > See https://gist.github.com/adunstan/32ad224d7499d2603708
>
On Sep 22, 2015 8:58 PM, "Andrew Dunstan" wrote:
>
>
>
> On 09/22/2015 12:16 PM, Shulgin, Oleksandr wrote:
>>
>> Hi Hackers,
>>
>> I've recently stumbled upon a problem with table bloat estimation in
case there are columns of type JSON.
>>
>> The quick bloat estimation queries use sum over pg_stat
On 09/22/2015 12:16 PM, Shulgin, Oleksandr wrote:
Hi Hackers,
I've recently stumbled upon a problem with table bloat estimation in
case there are columns of type JSON.
The quick bloat estimation queries use sum over pg_statistic.stawidth
of table's columns, but in case of JSON the correspo
13 matches
Mail list logo
