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:
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 described originally would
On 2008-02-23 07:08, Dean Gibson (DB Administrator) wrote:
...
SELECT word1, word1
FROM S JOIN txt ON word = word1
WHERE type1 = int1 AND type2 = int2;
...
Oops that should be:
SELECT word1, word2
FROM S JOIN txt ON word = word1
WHERE type1 = int1 AND type2 = int2;
--
Mail to my
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 S
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 (below)?
SELECT
On 2008-02-22 12:49, Kynn Jones wrote:
Of course, I expect that using views Vint1 and Vint2... would
result in a loss in performance relative to a version that used bona
fide tables Tint1 and Tint2. My question is, how can I minimize
this performance loss?
That used to be my thoughts too,
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 before,
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
10 matches
Mail list logo
