Re: BUG #3657: Performance leaks when using between of two equal dates

From: Tiago Daniel Jacobs <tiago(at)mdtestudio(dot)com(dot)br>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #3657: Performance leaks when using between of two equal dates
Date: 2007-10-06 16:51:45
Message-ID: 4707BD21.7020305@mdtestudio.com.br
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<small><font face="Arial">I run analyze on the database every day.<br>
<br>
And before post this bug-report, a VACUUM FULL, REINDEX, ANALYZE on
entire DB.<br>
<br>
Note that the type of field is date, so, between two equal values is
exactly the same that equal operator.<br>
<br>
On my system I made a check if the two dates are equal then rewrite SQL
code, but I think that the big portion of users don't do this.<br>
<br>
I would like to see it corrected, and help to make postgreSQL better.<br>
<br>
Please ask me if need more information.<br>
<br>
PS: I consider this as a BUG, since the query simply don't return. And
for end users is obvious that it work as the same as "="&nbsp; operator.
But, if it is not a BUG, i'm so sorry!<br>
<br>
Best Regards,<br>
Tiago<br>
</font></small><br>
Tom Lane escreveu:
<blockquote cite="mid:24828(dot)1191688097(at)sss(dot)pgh(dot)pa(dot)us" type="cite">
<pre wrap="">Alvaro Herrera <a class="moz-txt-link-rfc2396E" href="mailto:alvherre(at)commandprompt(dot)com">&lt;alvherre(at)commandprompt(dot)com&gt;</a> writes:
</pre>
<blockquote type="cite">
<pre wrap="">Tiago Daniel Jacobs wrote:
</pre>
<blockquote type="cite">
<pre wrap="">" -&gt; Index Scan using idx_agreg_sig_2007_09__data_dt_data on
agreg_sig_2007_09 agreg_sig (cost=0.00..8.70 rows=1 width=59) (actual
time=7.143..4924.607 rows=178866 loops=1)"
" Index Cond: ((data_dt_data &gt;= '2007-09-01'::date) AND
(data_dt_data &lt;= '2007-09-01'::date))"
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
</pre>
<blockquote type="cite">
<pre wrap="">Please do ANALYZE agregados.agreg_sig and try the query again. The
indexscan is grossly misestimated.
</pre>
</blockquote>
<pre wrap=""><!---->
Not sure that it's ANALYZE's fault. Since we currently use the same
selectivity estimators for &gt; and &gt;= (and likewise for &lt; and &lt;=), we
have no hope of getting edge cases correct. Most of the time the
stats are crude enough that it doesn't matter, but sometimes the
edge value is common and then it does matter. I've been wondering
if it would be worth the trouble to introduce scalarlesel and
scalargesel estimators ...

regards, tom lane
</pre>
</blockquote>
<br>
</body>
</html>

Attachment Content-Type Size
unknown_filename text/html 2.4 KB

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Alessandra Bilardi 2007-10-08 09:44:27 BUG #3658: I've got disk-full errors when insert relational tables.
Previous Message Tom Lane 2007-10-06 16:28:17 Re: BUG #3657: Performance leaks when using between of two equal dates