I have worked round the issue by using 2 separate queries with the LIMIT
construct.
LogSN and create_time are indeed directly correlated, both monotonously
increasing, occasionally with multiple LogSN's having the same create_time.
What puzzles me is why the query with COUNT, MIN, MAX uses id
At 01:20 06/01/21, Jim C. Nasby wrote:
BTW, these queries below are meaningless; they are not equivalent to
min(logsn).
> esdt=> explain analyze select LogSN from Log where create_time <
> '2005/10/19' order by create_time limit 1;
Thank you for pointing it out.
It actually returns the min(l
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> On Fri, Jan 20, 2006 at 12:35:36PM +0800, K C Lau wrote:
> Here's the problem... the estimate for the backwards index scan is *way*
> off:
>> -> Limit (cost=0.00..1.26 rows=1 width=4) (actual
>> time=200032.928..200032.931 rows=1 loops=1)
>> -> Inde
On Fri, Jan 20, 2006 at 12:35:36PM +0800, K C Lau wrote:
Here's the problem... the estimate for the backwards index scan is *way*
off:
> -> Limit (cost=0.00..1.26 rows=1 width=4) (actual
> time=200032.928..200032.931 rows=1 loops=1)
>-> Index Scan Backward using pk_log on
>
The following query took 17 seconds:
select count(LogSN), min(LogSN), max(LogSN) from Log where create_time <
'2005/10/19';
Figuring that getting the count will involve scanning the database, I took
it out, but the new query took 200 seconds:
select min(LogSN), max(LogSN) from Log where crea
