On Thu, Jun 23, 2005 at 16:13:24 +0800,
laser <[EMAIL PROTECTED]> wrote:
>
> This thread make me to think about the question:
> could this "feature" be used in select count(*) type
> query that force it to use index?
count(*) can already be helped by indexes, but probably not the way you think.
Tom Lane wrote:
Richard Huxton writes:
laser wrote:
Aggregate (cost=19638.60..19638.60 rows=1 width=0) (actual
time=1567.317..1567.318 rows=1 loops=1)
-> Seq Scan on partial_idx_t (cost=1.00..18327.88
rows=524288 width=0) (actual time=0.046..906.747 rows=524288 loops=1)
To
Richard Huxton writes:
> laser wrote:
>> Aggregate (cost=13933.39..13933.39 rows=1 width=0) (actual
>> time=1901.761..1901.762 rows=1 loops=1)
>> -> Index Scan using partial_idx on partial_idx_t (cost=0.00..12622.93
>> rows=524183 width=0) (actual time=0.130..1230.634 rows=524288 loops=1)
>> Index
laser wrote:
> This thread make me to think about the question:
> could this "feature" be used in select count(*) type
> query that force it to use index?
No. Because of issues with concurrent updates to the table. See archives
for discussion.
> I make a little test, but found a strange phenoment
This thread make me to think about the question:
could this "feature" be used in select count(*) type
query that force it to use index?
I make a little test, but found a strange phenoment,
created a simple table:
create table partial_idx_t(id serial, f1 integer, f2 text);
then insert many rows
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> Has anyone looked at how hard it would be to identify impossible
> conditions as part of planning the query?
The question in my mind is not so much how hard it would be as how many
cycles we would waste trying to prove things that won't be true for
99.9
On Tue, Jun 21, 2005 at 10:33:45PM +0100, Simon Riggs wrote:
> On Tue, 2005-06-21 at 16:29 -0400, Tom Lane wrote:
> > > create index idx1 on tenk (col1) where col1 > 1 and col1 < 10;
> >
> > > explain select * from tenk where col1 > 5 and col1 < -5;
> > > [ uses that index ]
> >
> > This is a per
On Tue, 2005-06-21 at 16:29 -0400, Tom Lane wrote:
> > create index idx1 on tenk (col1) where col1 > 1 and col1 < 10;
>
> > explain select * from tenk where col1 > 5 and col1 < -5;
> > [ uses that index ]
>
> This is a perfectly legitimate situation.
Like I said, its correct. I didn't suggest
Simon Riggs <[EMAIL PROTECTED]> writes:
> Sweating over the logic of the theorem prover, I notice it doesn't
> actually bother to complete an accurate test.
Sure it does.
> create index idx1 on tenk (col1) where col1 > 1 and col1 < 10;
> explain select * from tenk where col1 > 5 and col1 < -5;
>
Sweating over the logic of the theorem prover, I notice it doesn't
actually bother to complete an accurate test. I can't see that it
produces an error, but I thought I would raise it, if only to share my
annoyance at the realisation of how it does things. :-(
drop table tenk;
create table tenk (c
10 matches
Mail list logo
