Hello! I'm not sure if this belongs to this mailing list, if not, please
tell me to redirect to where it belongs.
I have a query that does COUNT, LEFT JOIN and GROUP BY from two tables.
One has 85000 records, and other has 100 records. I've been running
the tests on 7.4.3, with SET ENABLE_SEQS
Mike,
Please send the EXPLAIN ANALYZE of the two versions of the query.
Best Regards,
Otto
- Original Message -
From: "Mario Splivalo" <[EMAIL PROTECTED]>
To:
Sent: Friday, October 21, 2005 1:13 PM
Subject: [SQL] Postgres 7.4.9 slow!
Hello! I'm not sure if this belongs to this mai
On Fri, 2005-10-21 at 14:01 +0200, Havasvölgyi Ottó wrote:
> Mike,
>
> Please send the EXPLAIN ANALYZE of the two versions of the query.
There they are, they are both the same:
join_test=# select version();
version
--
On Friday 21 October 2005 14:34, Mario Splivalo wrote:
| On Fri, 2005-10-21 at 14:01 +0200, Havasvölgyi Ottó wrote:
| > Mike,
| >
| > Please send the EXPLAIN ANALYZE of the two versions of the query.
^^^
| There they are, they are both the same:
|
| join_test=# sele
Hi,
I've got the following table (contents not really relevant):
CREATE TABLE _rating_params (
id SERIAL PRIMARY KEY,
letter CHAR(1) NOT NULL CHECK (letter = 'E' OR letter = 'F'),
superparam_id INTEGER REFERENCES _rating_params,
seq_num INTEGER NOT NULL DEFAULT 1,
name_id INTEGER NOT N
Mario Splivalo <[EMAIL PROTECTED]> writes:
> I have a query that does COUNT, LEFT JOIN and GROUP BY from two tables.
> One has 85000 records, and other has 100 records. I've been running
> the tests on 7.4.3,
Your later message shows 7.4.8. Which is it?
> But, now I downloaded postgres 7.4.9
On Fri, 2005-10-21 at 10:20 -0400, Tom Lane wrote:
> Mario Splivalo <[EMAIL PROTECTED]> writes:
> > I have a query that does COUNT, LEFT JOIN and GROUP BY from two tables.
> > One has 85000 records, and other has 100 records. I've been running
> > the tests on 7.4.3,
>
> Your later message sho
Wiebe Cazemier <[EMAIL PROTECTED]> writes:
> which I manipulate with the view "rating_params". The delete rules on this
> view
> act very strangely.
The rule that actually deletes the rows from the underlying has to fire
last, since the rows are gone from the view (and hence from OLD) the
moment
Tom Lane wrote:
> The rule that actually deletes the rows from the underlying has to fire
> last, since the rows are gone from the view (and hence from OLD) the
> moment you delete them.
A quote from the postgresql manual:
"But for ON UPDATE and ON DELETE rules, the original query is done after
Wiebe Cazemier <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>>> The rule that actually deletes the rows from the underlying has to fire
>>> last, since the rows are gone from the view (and hence from OLD) the
>>> moment you delete them.
> A quote from the postgresql manual:
> "But for ON UPDATE
Hi All,
sorry for posting another question on bytea fields, i searched in the
Forum and all over the net and could not find the answer, although it
seems pretty basic to me.
What i want to to is the follwing:
1. Create a picure in the Linux Shell
2. Insert into a bytea field
3. Retrieve the p
Tom Lane wrote:
A quote from the postgresql manual:
"But for ON UPDATE and ON DELETE rules, the original query is done after the
actions added by rules. This ensures that the actions can see the to-be-updated
or to-be-deleted rows"
Yes, I know that quote. I wrote it. It's not relevant her
Wiebe Cazemier <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Hmm ... this appears to be a bug in EXPLAIN ANALYZE: it really should
>> bump the CommandCounter between plan trees, but fails to ...
> Is this something I have to report?
Nah, I fixed it already (only in CVS HEAD though).
On 2005-10-21 09:47, Tom Lane wrote:
Alex Turner <[EMAIL PROTECTED]> writes:
It appears that casting to a char() causes spaces to be stripped (ignored) from
the string:
mls=# select length('123 '::char(8));
length
3
(1 row)
I'm not sure about anyone else, but I would pers
"Dean Gibson (DB Administrator)" <[EMAIL PROTECTED]> writes:
> I remember that discussion, and I was for the change. However, upon
> doing some testing after reading the above, I wonder if the
> blank-stripping isn't too aggressive. I have a CHAR(6) field (say,
> named Z) that has "abc " in
Tom Lane wrote:
"Dean Gibson (DB Administrator)" <[EMAIL PROTECTED]> writes:
I remember that discussion, and I was for the change. However, upon
doing some testing after reading the above, I wonder if the
blank-stripping isn't too aggressive. I have a CHAR(6) field (say,
named Z) that ha
16 matches
Mail list logo
