Lists writes:
> I already had a separate index on uid
> CREATE INDEX idx_user_comments_uid
> ON user_comments
> USING btree
> (uid);
> Under the circumstances, shouldn't a bitmap of those 2 indexes be far
> faster than using just the date index (compared to the old plan, n
Tom Lane wrote:
Lists writes:
The query
select comment_date
from user_comments
where user_comments.uid=1
order by comment_date desc limit 1
Explain:
"Limit (cost=0.00..2699.07 rows=1 width=8) (actual
time=52848.785..52848.787 row
Lists writes:
> The query
> select comment_date
> from user_comments
> where user_comments.uid=1
> order by comment_date desc limit 1
> Explain:
> "Limit (cost=0.00..2699.07 rows=1 width=8) (actual
> time=52848.785..52848.787 rows=1 loops=1)"
> " ->
Merlin Moncure writes:
> On Thu, Apr 16, 2009 at 2:02 AM, Lists wrote:
>> select comment_date
>> from user_comments
>> where user_comments.uid=1
>> order by comment_date desc limit 1
> try this:
> create index comment_data_uid_idx on user_comments(uid, comment_date);
> select * from
On Thu, Apr 16, 2009 at 2:02 AM, Lists wrote:
>
> Right, because they do. If you think otherwise, demonstrate it.
> (bonnie tests approximating a reverse seqscan are not relevant
> to the performance of indexscans.)
>
> Working on it. I *think* I've seen this issue in the field, which is why I
>
create index foobar on table(row desc);
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
Josh Berkus wrote:
Tom,
Right, because they do. If you think otherwise, demonstrate it.
(bonnie tests approximating a reverse seqscan are not relevant
to the performance of indexscans.)
Working on it. I *think* I've seen this issue in the field, which is
why I brought it up in the first pl
On Fri, 10 Apr 2009, Tom Lane wrote:
Josh Berkus writes:
Not as far as I can tell. It looks to me like the planner is assuming
that a forwards index scan and a reverse index scan will have the same
cost.
Right, because they do. If you think otherwise, demonstrate it.
They do when the cor
Tom,
Right, because they do. If you think otherwise, demonstrate it.
(bonnie tests approximating a reverse seqscan are not relevant
to the performance of indexscans.)
Working on it. I *think* I've seen this issue in the field, which is
why I brought it up in the first place, but getting a g
Josh Berkus writes:
> Not as far as I can tell. It looks to me like the planner is assuming
> that a forwards index scan and a reverse index scan will have the same
> cost.
Right, because they do. If you think otherwise, demonstrate it.
(bonnie tests approximating a reverse seqscan are not r
Tom,
Now, while index scans (for indexes on disk) aren't 100% sequential
reads, it seems like we should be increasing (substantially) the
estimated cost of reverse index scans if the index is likely to be on
disk. No?
AFAICS this is already folded into random_page_cost.
Not as far as I can
Josh Berkus writes:
> Now, what that says to me is that for this system reverse sequential
> reads are 1/4 the speed of forwards reads. And from my testing
> elsewhere, that seems fairly typical of disk systems in general.
Well, that's because filesystems try to lay out files so that logically
All,
I was looking at these IOZone results for some NAS hardware and thinking
about index scans:
Children see throughput for 6 readers = 72270.04 KB/sec
Parent sees throughput for 6 readers = 72269.06 KB/sec
Min throughput per process = 11686.53
13 matches
Mail list logo
