Tom Lane wrote:
> "Scott Marlowe" <[EMAIL PROTECTED]> writes:
>> Note that, at least in older versions, MySQL completely materialized a
>> temporary table from a view, then used that for the view. This is
>> horribly inefficient, and results in a lot of people thinking views
>> are slow. Not sure
On Sun, Nov 2, 2008 at 7:40 PM, Martin Gainty <[EMAIL PROTECTED]> wrote:
> does anyone know if postgres support 'refresh' of applicable index(es) of a
> materialized view on refresh?
Postgresql has no built in support for materialized views. If you
follow the excellent tutorial on how to make yo
l@postgresql.org
> Subject: Re: [GENERAL] Performance of views
> Date: Sun, 2 Nov 2008 21:22:24 -0500
> From: [EMAIL PROTECTED]
>
> "Scott Marlowe" <[EMAIL PROTECTED]> writes:
> > Note that, at least in older versions, MySQL completely materialized a
> &g
We've been toying around with reworking our years old database schema and
replacing the old tables with updatable views into the new schema. The only
real problem we've had with it is that queries to one of our views seem to
be joining on unnecessary tables because the view does the join. We don'
"Scott Marlowe" <[EMAIL PROTECTED]> writes:
> Note that, at least in older versions, MySQL completely materialized a
> temporary table from a view, then used that for the view. This is
> horribly inefficient, and results in a lot of people thinking views
> are slow. Not sure if this has been addr
On Sun, Nov 2, 2008 at 6:39 PM, Stephen Frost <[EMAIL PROTECTED]> wrote:
> Simon,
>
>> * Higher overhead mapping to original tables and indexes
>
> This just plain isn't true in PG, at least, and I'd think most other
> sensible databases..
Note that, at least in older versions, MySQL completely
Simon,
* Simon Windsor ([EMAIL PROTECTED]) wrote:
> Generally, I have avoided using VIEWS within application code and only
> used them for client interfaces, the sole reason being the performance
> of views against tables.
Views really shouldn't have a large impact on overall performance. In
>> Am I right to avoid to VIEWS within application code?
How one uses views is more a matter of taste and best practices, than
a matter of rules like this. Frankly, this "rule" sounds rather ill
conceived.
My feeling is that views can be difficult to maintain when they are
nested, but otherwise
On Sun, Nov 2, 2008 at 4:11 PM, Simon Windsor
<[EMAIL PROTECTED]> wrote:
> Hi
>
> Generally, I have avoided using VIEWS within application code and only used
> them for client interfaces, the sole reason being the performance of views
> against tables.
Have you confirmed this belief with tests? O
Hi
Generally, I have avoided using VIEWS within application code and only
used them for client interfaces, the sole reason being the performance
of views against tables.
Changes to database over the past few years appear to have improved the
performance of views, but I am still not comfortab
Steffen Boehme <[EMAIL PROTECTED]> writes:
> FROM
> ss_order_orderitems a
> LEFT JOIN ss_order_affiliate_tracking b ON a.order_id = b.order_id,
> ss_shops c
> WHERE
> (a.order_id = b.order_id OR b.order_id IS NULL) AND
What is that last line doing there? It's completely redunda
Hello there,
i have a short question ...
I have a few tables (at the moment "only" 3 for testing), over which
will by made a query in this form:
SELECT
a.orderitem_id,
a.transaction_id,
a.order_id,
a.shop_id,
a.quantity,
a.price,
b.affiliat
12 matches
Mail list logo
