* Bruno Wolff III [EMAIL PROTECTED] wrote:
snip
This gets brought up a lot. The problem is that the index doesn't include
information about whether the current transaction can see the referenced
row. Putting this information in the index will add significant overhead
to every update and the
Enrico Weigelt wrote:
Bruno Wolff III wrote:
This gets brought up a lot. The problem is that the index doesn't include
information about whether the current transaction can see the referenced
row. Putting this information in the index will add significant overhead
to every update and the
On Wed, May 25, 2005 at 09:29:36AM +0800, Christopher Kings-Lynne wrote:
--MSSQL's ability to hit the index only and not having
to go to the table itself results in a _big_
performance/efficiency gain. If someone who's in
development wants to pass this along, it would be a
nice addition to
select count(*) from mtable where day='Mon'
Results:
1. P3 600 512MB RAM MSSQL. It takes about 4-5 secs to
run. If I run a few queries and everything is cached,
it is sometimes just 1 second.
2. Athlon 1.3 Ghz 1GB RAM. PostgreSQL takes 7 seconds.
I have played with the buffers setting and
Post the result of this for us:
explain analyze select count(*) from mtable where
day='Mon';
On both machines.
Hi Chris --
PostgreSQL Machine:
Aggregate (cost=140122.56..140122.56 rows=1 width=0)
(actual time=24516.000..24516.000 rows=1 loops=1)
- Index Scan using day on mtable
mark durrant wrote:
PostgreSQL Machine:
Aggregate (cost=140122.56..140122.56 rows=1 width=0)
(actual time=24516.000..24516.000 rows=1 loops=1)
- Index Scan using day on mtable
(cost=0.00..140035.06 rows=35000 width=0) (actual
time=47.000..21841.000 rows=1166025 loops=1)
Index Cond:
Mark,
MSSQL Machine:
That Explain Analyze command doesn't work for MSSQL,
try this:
set showplan_all on
go
select ...
go
Harald
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
On Tue, May 24, 2005 at 08:36:36 -0700,
mark durrant [EMAIL PROTECTED] wrote:
--MSSQL's ability to hit the index only and not having
to go to the table itself results in a _big_
performance/efficiency gain. If someone who's in
development wants to pass this along, it would be a
nice
I'm far from an expert, so this may be off-base... but
perhaps a suggestion would be to allow a hint to be
sent to the optimizer if the user doesn't care that
the result is approximate maybe then this wouldn't
require adding more overhead to the indexes.
MSSQL has something like this with
Until you start worrying about MVC - we have had problems with the
MSSQL implementation of read consistency because of this 'feature'.
Alex Turner
NetEconomistOn 5/24/05, Bruno Wolff III [EMAIL PROTECTED] wrote:
On Tue, May 24, 2005 at 08:36:36 -0700,mark durrant [EMAIL PROTECTED] wrote:
Folks,
This gets brought up a lot. The problem is that the
index doesn't include
information about whether the current transaction
can see the referenced
row. Putting this information in the index will add
significant overhead
to every update and the opinion of the developers is
Pretty much. There has been discussion about allowing index-only access
to
frozen tables, i.e. archive partitions. But it all sort of hinges on
someone implementing it and testing
Would be interesting as a parameter to set at index creation (ie. if you
know this table will have a
On Tue, May 24, 2005 at 04:35:14PM -0700, Josh Berkus wrote:
Pretty much. There has been discussion about allowing index-only access to
frozen tables, i.e. archive partitions. But it all sort of hinges on
someone implementing it and testing
Is there any way to expose the planner
Michael Stone wrote:
On Tue, May 24, 2005 at 04:35:14PM -0700, Josh Berkus wrote:
Pretty much. There has been discussion about allowing index-only
access to frozen tables, i.e. archive partitions. But it all sort
of hinges on someone implementing it and testing
Is there any way to
--As Chris pointed out, how real-world is this test?
His point is valid. The database we're planning will
have a lot of rows and require a lot of summarization
(hence my attempt at a test), but we shouldn't be
pulling a million rows at a time.
If you want to do lots of aggregate analysis, I
Hi,
I have some experience with MSSQL and am examining
PostgreSQL. I'm running under Windows. I like what I
see so far, but I'm hoping for some performance
advice:
1. My test database has 7 million records.
2. There are two columns - an integer and a char
column called Day which has a random
16 matches
Mail list logo
