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 if this has
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
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? Or just
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 use
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
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
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 addressed
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
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
temporary table from a view, then used that for the view. This is
horribly
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 your
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,
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 redundant and
12 matches
Mail list logo
