Tom Lane writes:
> The long and the short of it is this: having unlogged matviews in 9.3
> is not worth taking that risk for. IMO anyway.
FWIW, +1
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mailing list (pgsq
On 05/05/13 10:41, Kevin Grittner wrote:
[...]
removing unlogged matviews for 9.3
[...]
So you are going to unlog the unlogged matviews from 9.3? :-)
More seriously, I think this will result in a better solution for 9.4 -
as it seems to me to be too rushed to fix it now
Cheers,
Gavin.
Tom Lane wrote:
> Kevin Grittner writes:
>> What do you see that I'm missing?
>
> TBH, if I had 20-20 foresight, we'd not be having this
> discussion: either I could see that you're right and this patch
> isn't going to cause us enormous pain, or I could put my finger
> on exactly where and why
... btw, I noticed a minor misfeature in the current implementation:
regression=# select pg_relation_size('int8_tbl');
pg_relation_size
--
8192
(1 row)
regression=# create materialized view mv1 as select * from int8_tbl;
SELECT 5
regression=# select pg_relation_size
Kevin Grittner writes:
> What do you see that I'm missing?
TBH, if I had 20-20 foresight, we'd not be having this discussion:
either I could see that you're right and this patch isn't going to
cause us enormous pain, or I could put my finger on exactly where
and why it's going to hurt us. But I
Tom Lane wrote:
> Kevin Grittner writes:
>> Tom Lane wrote:
>>> The current matview design gets around this problem by
>>> requiring that transition between scannable and unscannable
>>> states involve a complete table rewrite, and thus the
>>> transactionality issue can be hidden behind a trans
On 5/2/13 6:00 PM, Kevin Grittner wrote:
> (1) The ability to count on the results from a query which
> references a matview to reflect valid data from *some* point in
> time.
>
> (2) The ability to create unlogged materialized views.
>
> (3) The ability to consider a zero-length matview heap
Kevin Grittner writes:
> Tom Lane wrote:
>> The current matview design gets around this problem by requiring
>> that transition between scannable and unscannable states involve
>> a complete table rewrite, and thus the transactionality issue can
>> be hidden behind a transactional update of the m
Tom Lane wrote:
> The current matview design gets around this problem by requiring
> that transition between scannable and unscannable states involve
> a complete table rewrite, and thus the transactionality issue can
> be hidden behind a transactional update of the matview's
> pg_class.relfileno
Josh Berkus writes:
> As I understand it, we don't currently have any mechanism in Postgres
> which would cause allocated-but-empty pages.
That's not correct: the situation can easily arise after a database
crash. (The scenario is that we've done smgrextend to add the first
page to the file, but
> Tom wants to ditch (2) to allow the others. Robert wants to ditch
> (1) to allow the others. I want to ditch (3) to allow the others.
> Andres wants (3) and has not expressed an opinion on which he would
> prefer to give up to get it. I believe Josh Berkus has mentioned
> how useful he think
Tom has refactored where and how certain parts of the work get done
for materialized views, reducing issues with modularity violations.
I have been and will continue to review his changes to better
understand how the pieces of the code fit together, so hopefully he
won't need to do so much with fut
12 matches
Mail list logo
