On Fri, May 7, 2010 at 11:35 AM, Tom Lane wrote:
> "Kevin Grittner" writes:
>> Alexander Korotkov wrote:
I just don't find why it is coincidence. I think that such plan
will always produce result ordered by two columns, because such
nested index scan always produce this result.
>
"Kevin Grittner" writes:
> Alexander Korotkov wrote:
>>> I just don't find why it is coincidence. I think that such plan
>>> will always produce result ordered by two columns, because such
>>> nested index scan always produce this result.
> Assuming a nested index scan, or any particular plan,
Alexander Korotkov wrote:
> Alexander Korotkov wrote:
>>> Well, no, because that plan wouldn't produce the specified
>>> ordering; or at least it would be a lucky coincidence if it did.
>>> It's only sorting on t1.value.
>>>
>> I just don't find why it is coincidence. I think that such plan
>>
I found my mistake. My supposition is working only if value column in t1
table is unique. But if I replace the index by unique one then plan is the
same.
On Mon, May 3, 2010 at 5:57 PM, Alexander Korotkov wrote:
> Well, no, because that plan wouldn't produce the specified ordering;
>> or at least
>
> Well, no, because that plan wouldn't produce the specified ordering;
> or at least it would be a lucky coincidence if it did. It's only
> sorting on t1.value.
>
I just don't find why it is coincidence. I think that such plan will always
produce result ordered by two columns, because such neste
=?KOI8-R?B?68/Sz9TLz9cg4czFy9PBzsTS?= writes:
> So PostgreSQL planner can produce the plan I need but it doesn't produce
> this plan when I specify particular second ordering column.
Well, no, because that plan wouldn't produce the specified ordering;
or at least it would be a lucky coincidence i
Hello, everybody!
I'm using PostgreSQL 8.4.3, compiled by Visual C++ build 1400, 32-bit on
Windows XP SP3.
I use following data model for issue reproducing.
CREATE TABLE test1
(
id integer NOT NULL,
"value" double precision,
CONSTRAINT test1_pkey PRIMARY KEY (id)
);
CREATE INDEX test1_valu
I'm guessing your data is actually more "clustered" than the
"correlation" statistic thinks it is.
Alex Turner wrote:
> trendmls=# explain analyze select listnum from propmain where
> listprice<=30 and listprice>=20;
Is that a database of properties like land/houses?
I'm guessing your data is actually more "clustered" than the
"correlation" stastic thinks it is.
Alex Turner wrote:
> trendmls=# explain analyze select listnum from propmain where
> listprice<=30 and listprice>=20;
Is that a database of properties like land/houses?
If
On Tue, 2005-03-22 at 14:36 -0500, Alex Turner wrote:
> I will use an index 220-300, but not 200-300.
> ...
> Seq Scan on propmain (cost=0.00..15517.56 rows=6842 width=4) (actual
> time=0.039..239.760 rows=6847 loops=1)
> ...
> Index Scan using propmain_listprice_i on propmain
> (cost=0.00..22
This helps a bit when I set it to 1000 - but it's still pretty bad:
I will use an index 220-300, but not 200-300.
Alex
trendmls=# explain analyze select listnum from propmain where
listprice<=30 and listprice>=20;
QUERY PLAN
Alex Turner wrote:
I get the following output from explain analyze on a certain subset of
a large query I'm doing.
Try increases the statistics on the listprice column with alter
table and then re-run analyze.
alter table foo alter column set statistics
Sincerely,
Joshua D. Drake
From the look
I get the following output from explain analyze on a certain subset of
a large query I'm doing.
>From the looks of it, I need to increase how often postgres uses an
index over a seq scan, but I'm not sure how to do that. I looked
through the run-time configuration docs on the website, but didn't
13 matches
Mail list logo
