Dear Tom,
Not sure about Otto's exact problem, but he did mention views, and I'd feel
more comfortable if you told me that view-based queries are re-planned based
on actual conditions etc. Are they?
Also, if you find it unlikely (or very rare) then it might be a configurable
parameter. If so
Dear Virag,
AFAIK aggregates aren't indexed in postgres (at least not before 8.1, which
indexes min and max, iirc).
Also, I don't think you need to exactly determine the trace_id. Try this one
(OTOH; might be wrong):
select DISTINCT ON (a.trace_id, a.seq_no) -- See below
b.gc_minor
Dear Tom,
On 2005.12.21. 20:34, Tom Lane wrote:
=?ISO-8859-2?Q?Sz=FBcs_G=E1bor?= <[EMAIL PROTECTED]> writes:
Query is:
SELECT idopont WHERE muvelet = x ORDER BY idopont LIMIT 1.
Much the best solution for this would be to have an index on
(muvelet, idopont)
--- perhaps you can reorder
Dear Gurus,
Version: 7.4.6
I use a query on a heavily indexed table which picks a wrong index
unexpectedly. Since this query is used in response to certain user
interactions thousands of times in succession (with different constants),
500ms is not affordable for us. I can easily work around t
Dear Gurus,
System: Debian "Woody" 2.4.28
Version: PostgreSQL 7.4.8
I have a join which causes a better hash if I provide a "trivial" condition:
WHERE m.nap > '1900-01-01'::date
This is a date field with a minimum of '2005-06-21'. However, if I omit this
condition from the WHERE clause, I get a
Dear Gurus,
I don't think it's a bug, I just don't understand what's behind this. If
there's a paper or something on this, please point me there.
Version: 7.4.6
Locale: hu_HU (in case that matters)
Dump: see below sig.
Abstract:
Create a table with (at least) two fields, say i and o.
Create three
Dear Gurus,
Here is this strange query that can't find the optimum plan unless I disable
some scan modes or change the costs.
(A) is a 2x2.4GHz server with hw raid5 and v7.3.4 database. It chooses
hashjoin.
(B) is a 300MHz server with 7200rpm ide and v7.4.2 database. It chooses
seqscan.
If I dis
Dear Tom,
Thanks for your response.
- Original Message -
From: "Tom Lane" <[EMAIL PROTECTED]>
Sent: Monday, June 07, 2004 3:51 PM
> That's pretty hard to believe; particularly on modern machines, I'd
> think that moving it down would make more sense than moving it up.
> You're essentia
Dear Gurus,
Please feel free to show me to the archives if my question has already been
answered.
Last week I fumbled with CPU_TUPLE_COST and revealed that 4 out of 4 tested
queries improved by 10-60% if I changed it from 0.01 (default) to 0.40
(ugh). Setting it higher did not bring any improveme
Dear Tom,
Thanks for your early response.
An addition: the nastier difference increased by adding an index (it was an
essential index for this query):
func with param improved from 2700ms to 2300ms
func with constant improved from 400ms to 31ms
inline query improved from 390ms to 2ms
So a
Dear Gurus,
I have two SQL function that produce different times and I can't understand
why. Here is the basic difference between them:
CREATE FUNCTION test_const_1234 () RETURNS int4 AS '
SELECT ... 1234 ... 1234 1234 ...
' LANGUAGE 'SQL';
CREATE FUNCTION test_param (int4) RETURNS int4 A
Dear Gurus,
I have a query discussed here earlier that suffers heavily from "lack of
view flattening" in v7.3. Following Tom's guidance, I made a conclusion to
that thread
(http://archives.postgresql.org/pgsql-performance/2003-05/msg00215.php)
and asked it to be confirmed or fixed, but I didn't ge
12 matches
Mail list logo
