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?
http://www.postgresql.org/doc
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> From: "Mischa Sandberg" <[EMAIL PROTECTED]>
>
> > If your company is currently happy with MySQL, there probably are
> > other (nontechnical) reasons to stick with it. I'm impressed that
> > you'd consider reconsidering PG.
>
> I'd like to second Mi
> Note that there ARE other options. While the inability to provide a
> speedy count is a "cost" of using an MVCC system, the ability to allow
> thousands of readers to run while updates are happening underneath them
> more than makes up for the slower aggregate performance.
IMO this depends on t
@Chris:
> > SELECT count(*) FROM the_table
> > => Seq scan -> takes about 12 sec
> This cannot be made O(1) in postgres due to MVCC. You just have to live
> with it.
bad news
BTW: in this case you could workaround
select reltuples from pg_class where relname='the_table'
(yes, I know: presumes a
Hi,
I've experienced that PG up to current release does not make use of an index when
aggregating. Which of course may result in unacceptable answering times
This behaviour is reproducable on any table with any aggregat function in all of my
databases on every machine (PostgreSQL 7.4.2 on i386-
