I`m sorry, but why work around?
The overhead of "99%" of cases is so bigger? What about an "option"
like constraint exclusion...
I've worked around also, but would like to see this topic in a TODO or
further implementation.
Thanks by patience.
Kevin Grittner escreveu:
>>> On Sat, Oct 6, 2007 at 11:28 AM, in message <[EMAIL PROTECTED]>,
Tom Lane <[EMAIL PROTECTED]> wrote:
> I've been wondering
> if it would be worth the trouble to introduce scalarlesel and
> scalargesel estimators ...
FWIW, this is an issue we ran into:
http://archives.postgresql.org/pgsql-p
I run analyze on the database every day.
And before post this bug-report, a VACUUM FULL, REINDEX, ANALYZE on
entire DB.
Note that the type of field is date, so, between two equal values is
exactly the same that equal operator.
On my system I made a check if the two dates are equal then rewri
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tiago Daniel Jacobs wrote:
>> "-> 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: ((dat
Tiago Daniel Jacobs wrote:
> type of data_dt_Data is date
>
> -- The slow way
> EXPLAIN ANALYZE select * from agregados.agreg_sig where data_dt_Data between
> '20070901' and '20070901';
>
> "Result (cost=0.00..29.05 rows=4 width=84) (actual time=7.146..5234.762
> rows=178866 loops=1)"
> " ->
The following bug has been logged online:
Bug reference: 3657
Logged by: Tiago Daniel Jacobs
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.4
Operating system: Linux
Description:Performance leaks when using between of two equal dates
Details:
Hi, please an
