Re: [PERFORM] Postgres not willing to use an index?

2009-02-09 Thread Mario Splivalo
Mario Splivalo wrote: Robert Haas wrote: jura=# set enable_seqscan to false; SET jura=# explain analyze select * from transactions where transaction_time_commit between '2008-01-01' and '2008-01-31 23:59:59'; QUERY PLAN -

Re: [PERFORM] Postgres not willing to use an index?

2009-02-09 Thread Mario Splivalo
Robert Haas wrote: On Fri, Feb 6, 2009 at 12:41 PM, Kevin Grittner wrote: Robert Haas wrote: What's weird about this example is that when he sets enable_seqscan to off, the bitmap index scan plan is actually substantially faster, even though it in fact does scan nearly the entire heap. I don

Re: [PERFORM] Postgres not willing to use an index?

2009-02-09 Thread Mario Splivalo
Tom Lane wrote: Hardly surprising --- a search on the index's lowest-order column would require scanning practically all of the index. (If you think about the ordering of the index entries you'll see why.) If this is a typical query then you need a separate index on transaction_time_commit.

Re: [PERFORM] Postgres not willing to use an index?

2009-02-06 Thread Robert Haas
On Fri, Feb 6, 2009 at 12:41 PM, Kevin Grittner wrote: Robert Haas wrote: >> What's weird about this example is that when he sets enable_seqscan to >> off, the bitmap index scan plan is actually substantially faster, even >> though it in fact does scan nearly the entire heap. I don't >> und

Re: [PERFORM] Postgres not willing to use an index?

2009-02-06 Thread Kevin Grittner
>>> Robert Haas wrote: > What's weird about this example is that when he sets enable_seqscan to > off, the bitmap index scan plan is actually substantially faster, even > though it in fact does scan nearly the entire heap. I don't > understand how it can be faster to scan the index and the heap

Re: [PERFORM] Postgres not willing to use an index?

2009-02-06 Thread Robert Haas
On Fri, Feb 6, 2009 at 11:14 AM, Tom Lane wrote: > Mario Splivalo writes: >> Besides PK and uq-constraint indices I have this index: > >> CREATE INDEX transactions_idx__client_data ON transactions >> USING btree (transaction_client_id, transaction_destination_id, >> transaction_operator_id, trans

Re: [PERFORM] Postgres not willing to use an index?

2009-02-06 Thread Tom Lane
Mario Splivalo writes: > Besides PK and uq-constraint indices I have this index: > CREATE INDEX transactions_idx__client_data ON transactions > USING btree (transaction_client_id, transaction_destination_id, > transaction_operator_id, transaction_application_id, > transaction_time_commit) > SE

Re: [PERFORM] Postgres not willing to use an index?

2009-02-06 Thread Grzegorz Jaƛkiewicz
On Fri, Feb 6, 2009 at 3:43 PM, Mario Splivalo wrote: > Besides PK and uq-constraint indices I have this index: > > CREATE INDEX transactions_idx__client_data ON transactions > USING btree (transaction_client_id, transaction_destination_id, > transaction_operator_id, transaction_application_id, >

[PERFORM] Postgres not willing to use an index?

2009-02-06 Thread Mario Splivalo
I have a table, like this: CREATE TABLE transactions ( transaction_id integer NOT NULL DEFAULT nextval('transactions_seq'::regclass), transaction_type integer NOT NULL, transaction_client_id integer NOT NULL, transaction_destination_id integer NOT NULL, transaction_operator_id integer