On Fri, Apr 05, 2013 at 11:17:30AM +0200, Nicolas Barbier wrote:
> 2013/4/5 Noah Misch :
> > On Thu, Apr 04, 2013 at 12:28:01PM +0200, Nicolas Barbier wrote:
> >> +1. Having unlogged matviews without having incremental updates yet,
> >> isn't super useful anyway.
> >
> > I would have surmised the o
Noah Misch wrote:
> On Thu, Apr 04, 2013 at 12:28:01PM +0200, Nicolas Barbier wrote:
>> +1. Having unlogged matviews without having incremental updates
>> yet, isn't super useful anyway.
>
> I would have surmised the opposite
Hmm. I was thinking about the fact that a full refresh can be
unlogge
2013/4/5 Noah Misch :
> On Thu, Apr 04, 2013 at 12:28:01PM +0200, Nicolas Barbier wrote:
>
>> +1. Having unlogged matviews without having incremental updates yet,
>> isn't super useful anyway.
>
> I would have surmised the opposite: since an unlogged MV requires a full
> refresh at unpredictable m
On Thu, Apr 04, 2013 at 12:28:01PM +0200, Nicolas Barbier wrote:
> 2013/4/3 Tom Lane :
> > And if you're absolutely convinced that unlogged matviews mustn't work as I
> > suggest, we can lose those from 9.3, too.
>
> +1. Having unlogged matviews without having incremental updates yet,
> isn't supe
Early versions of the matview patch had a relisvalid flag in
pg_class to determine whether the relation was scannable. The name
was chosen based on a similarity to the purpose of indisvalid,
although the proliferation of new bools for related issues left me
wondering if a "char" would be a better
2013/4/3 Tom Lane :
> Kevin Grittner writes:
>
>> To be honest, I don't think I've personally seen a single use case
>> for matviews where they could be used if you couldn't count on an
>> error if attempting to use them without the contents reflecting a
>> materialization of the associated query
Kevin Grittner writes:
> Tom Lane wrote:
>>> In fact, I'm going to go further and say that I do not like the
>>> entire concept of scannability, either as to design or
>>> implementation, and I think we should just plain rip it out.
> To be honest, I don't think I've personally seen a single use
Tom Lane wrote:
> Robert Haas writes:
>> Tom Lane wrote:
>>> In fact, I'm going to go further and say that I do not like the
>>> entire concept of scannability, either as to design or
>>> implementation, and I think we should just plain rip it out.
>
>> This has been my feeling from the beginni
Robert Haas writes:
> On Wed, Apr 3, 2013 at 10:59 AM, Tom Lane wrote:
>> In fact, I'm going to go further and say that I do not like the entire
>> concept of scannability, either as to design or implementation, and
>> I think we should just plain rip it out.
> This has been my feeling from the
On Wed, Apr 3, 2013 at 10:59 AM, Tom Lane wrote:
> In fact, I'm going to go further and say that I do not like the entire
> concept of scannability, either as to design or implementation, and
> I think we should just plain rip it out.
This has been my feeling from the beginning, so I'm happy to s
[ sorry for being slow to respond, things are crazy this week ]
Kevin Grittner writes:
> Tom Lane wrote:
>> Anyway, the immediate takeaway is that this represents a horribly
>> expensive way for pg_dump to find out which matviews aren't
>> scannable. The cheap way for it to find out would be if
Kevin Grittner wrote:
> Tom Lane wrote:
>> Another reason why I don't like this code is that
>> pg_relation_is_scannable is broken by design:
>>
>> relid = PG_GETARG_OID(0);
>> relation = RelationIdGetRelation(relid);
>> result = relation->rd_isscannable;
>> RelationClose(rel
Tom Lane wrote:
> Kevin Grittner writes:
>> Tom Lane wrote:
>>> So maybe I'm nuts to care about the performance of an
>>> assert-enabled backend, but I don't really find a 4X runtime
>>> degradation acceptable, even for development work. Does anyone
>>> want to fess up to having caused this, or
Kevin Grittner writes:
> Tom Lane wrote:
>> So maybe I'm nuts to care about the performance of an assert-enabled
>> backend, but I don't really find a 4X runtime degradation acceptable,
>> even for development work. Does anyone want to fess up to having caused
>> this, or do I need to start trac
Tom Lane wrote:
> Using HEAD's pg_dump, I see "pg_dump -s regression" taking 5
> seconds.
> On the other hand, running the same executable against the regression
> database on a 9.2 postmaster takes 1.2 seconds. Looks to me like we
> broke something performance-wise.
>
> A quick check with oprof
Using HEAD's pg_dump, I see "pg_dump -s regression" taking 5 seconds.
On the other hand, running the same executable against the regression
database on a 9.2 postmaster takes 1.2 seconds. Looks to me like we
broke something performance-wise.
A quick check with oprofile says it's all AllocSetCheck
16 matches
Mail list logo
