[Jim C. Nasby - Thu at 01:04:53PM -0500]
> What does
>
> SET enable_seqscan = false;
> EXPLAIN ANALYZE SELECT * FROM ...
>
> get you? Is it faster?
I was experimenting with this some weeks ago, by now our database server has
quite low load numbers and I haven't gotten any complaints about anyth
What does
SET enable_seqscan = false;
EXPLAIN ANALYZE SELECT * FROM ...
get you? Is it faster?
BTW, I suspect this behavior is because the estimates for the cost of an
index scan don't give an appropriate weight to the correlation of the
index. The 'sort and index' thread on this list from a fe
[Tobias Brox - Tue at 10:06:25AM +0800]
> [Tom Lane - Mon at 01:57:54PM -0400]
> > Your followup hasn't shown up here yet,
>
> I'll check up on that and resend it.
Hrm ... messed-up mail configuration I suppose. Here we go:
Paul McGarry unintentionally sent a request for more details off the l
[Tom Lane - Mon at 01:57:54PM -0400]
> Your followup hasn't shown up here yet,
I'll check up on that and resend it.
> but if the query is written like
> WHERE timestampcol >= now() - interval 'something'
> then the pre-8.0 planner is not capable of making a good estimate of the
> selectivi
Tobias Brox <[EMAIL PROTECTED]> writes:
>> What version of PostgreSQL are you using?
> Also answered in my follow-up - "not yet pg8" :)
Your followup hasn't shown up here yet, but if the query is written like
WHERE timestampcol >= now() - interval 'something'
then the pre-8.0 planner is n
[Michael Fuhr - Mon at 07:54:29AM -0600]
> The message subject is "timestamp indexing" but you don't mention
> whether you have an index on the timestamp column. Do you?
Yes. Sorry for not beeing explicit on that.
> Could you post an example query and its EXPLAIN ANALYZE output? If
> the query
On Mon, May 30, 2005 at 05:19:51PM +0800, Tobias Brox wrote:
>
> We have a production database with transaction-style data, in most of the
> tables we have a timestamp attribute "created" telling the creation time of
> the table row. Naturally, this attribute is always increasing.
The message sub
We have a production database with transaction-style data, in most of the
tables we have a timestamp attribute "created" telling the creation time of
the table row. Naturally, this attribute is always increasing.
By now we are hitting the limit where the table data does not fit in caches
anymore.
