Tom Lane <[EMAIL PROTECTED]> writes:
> Fixing this properly is a research project, and I haven't thought of any
> quick-and-dirty hacks that aren't too ugly to consider :-(
Just thinking out loud here. Instead of trying to peek inside the CASE
couldn't the optimizer just wrap the non-strict expr
"Dean Gibson (DB Administrator)" <[EMAIL PROTECTED]> writes:
> It turns out that even when I removed the CASE statement from the VIEW, the
> performance problem remained. I had to remove the conditional as well from
> the VIEW.
> cancel_date < expire_date AS canceled,
Yuck :-(
> Do you know w
It turns out that even when I removed the CASE statement from the VIEW, the
performance problem remained. I had to remove the conditional as well from
the VIEW.
To refresh your memory, there was this line in the VIEW (said VIEW being
the subject of the LEFT JOIN):
cancel_date < expire_date AS
"Dean Gibson (DB Administrator)" <[EMAIL PROTECTED]> writes:
> I could ask why a CASE statement is always non-nullable, but I don't think
> the answer would help be solve my problem. I suppose it's that even
> though my particular CASE statement has WHEN/ELSE values that come from the
> nullab
On Mon, 20 Sep 2004, Dean Gibson (DB Administrator) wrote:
> Okay, now for my big question: I searched high and low for a function that
> would return the minimum of two dates, and found none. Now you come up
> with "date_smaller", which works fine (as does "date_larger"), but where
> are those d
Ahh, that explains why a "plain" JOIN (which doesn't do what I need) gave
much better performance than the LEFT JOIN.
I could ask why a CASE statement is always non-nullable, but I don't think
the answer would help be solve my problem. I suppose it's that even
though my particular CASE statem
"Dean Gibson (DB Administrator)" <[EMAIL PROTECTED]> writes:
> Question: why do the last two column definitions in the second VIEW change
> the scan on _LicHD from indexed to sequential ??
It's the CASE that's getting you. The poor plan is basically because
the sub-view isn't getting "flattened
Tom Lane wrote on 2004-09-20 16:06:
"Dean Gibson (DB Administrator)" <[EMAIL PROTECTED]> writes:
> I have a view that when used, is slow:
... If you want useful help you need to be more complete.
I use views to "hide" tables so that I can populate new tables and then
atomically switch to them with
"Dean Gibson (DB Administrator)" <[EMAIL PROTECTED]> writes:
> I have a view that when used, is slow:
It's obvious that you haven't given us anything remotely like full
information here. AFAICT the "tables" in your view are actually
other views, plus it looks like your call to the view is a query
I have a view that when used, is slow:
CREATE VIEW "Data".genlic_a4avail AS
SELECT
genlic_a4.*,
last_action_date,
end_date,
canceled
FROMgenlic_a4
LEFT JOIN lic_hd USING( sys_id )
Hi there,
I'm having some problems with the performance on queries including a join.
for example:
SELECT members_data.pwd FROM emails,members_data WHERE emails.email =
'[EMAIL PROTECTED]' AND emails.uin = members_data.uin;
is a lot slower then extracting the join into 2 seperate queries like:
11 matches
Mail list logo
