On 2008-02-28 09:13, Tom Lane wrote:
A rule of thumb is that ORDER BY in a view is bad design, IMHO.
regards, tom lane
I was surprised to find out that apparently it's also a PostgreSQL
extension; standard SQL apparently disallows ORDER BY in VIEWs:
http://en.wik
On 2008-02-23 08:49, Dean Gibson (DB Administrator) wrote:
Why 10,000 views??? What's wrong with the ONE view above? You DON'T
want to be defining VIEWs based on actual tables VALUES; leave that
to the SELECT. For that matter, what's wrong with the final SELECT I
listed (b
On 2008-02-23 08:21, Kynn Jones wrote:
...
3. Why not write:
CREATE VIEW txt AS
SELECT a1.word AS word1, a1.type AS type1, a2.word AS word2,
a2.type AS type2
FROM T a1 [LEFT] JOIN T a2 USING( zipk ); -- Use "LEFT" if
appropriate
SELECT word1, word1
FROM
On 2008-02-23 07:08, Dean Gibson (DB Administrator) wrote:
...
SELECT word1, word1
FROM S JOIN txt ON word = word1
WHERE type1 = AND type2 = ;
...
Oops that should be:
SELECT word1, word2
FROM S JOIN txt ON word = word1
WHERE type1 = AND type2 = ;
--
Mail to my list address MUST
On 2008-02-23 05:59, Kynn Jones wrote:
On Fri, Feb 22, 2008 at 8:48 PM, Dean Gibson (DB Administrator)
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
...
Since you have experience working with views, let me ask you this.
The converse strategy to the one I describe
On 2008-02-22 12:49, Kynn Jones wrote:
Of course, I expect that using views V and V... would
result in a loss in performance relative to a version that used bona
fide tables T and T. My question is, how can I minimize
this performance loss?
That used to be my thoughts too, but I have found o
On 2008-02-12 13:35, Pallav Kalva wrote:
Hi,
...
Table Definitions
\d listing.listingstatus
Table "listing.listingstatus"
Column |Type
| Modifiers
-+-
> Old servers that housed 7.4 performed better than 8.1.4 version...are
> there any MAJOR performance hits with this version???
>
> I set the postgresql.conf setting to equal that of 7.4 and queries still
> run
> SLOW on 8.1.4...
We need to find a specific query that is slow now that was fast befo
> I'm having a problem with long running commits appearing in my database
> logs. It may be hardware related, as the problem appeared when we moved
> the database to a new server connected to a different disk array. The
> disk array is a lower class array, but still more than powerful enough
> to
> Last time I had this problem i solved it stopping website, restarting
> database, vacuumm it, run again website. But I guess this is going to
> happen again.
>
> I would like to detect and solve the problem. Any ideas to detect it?
Do you have very long transactions? Maybe some client that is c
I don't think I understand the idea behind this query. Do you really need
billing_reports twice?
> The query:
> explain analyze select
> w.appid,w.rate,w.is_subscribed,sum(w.hits) AS Hits ,sum(w.sius) AS IUs,
> sum(w.total_amnt) AS Total,sum(w.hits) * w.rate AS ByHits,
> sum(w.sius) * w.rate AS BY
11 matches
Mail list logo
