The first thing to check... Did you do a recent VACUUM ANALYZE? This
updates all the statistics. There are a number of places where it says
"rows=1000" which is usually the "I have no idea, let me guess 1000".
Also, there are a number of places where the estimates are pretty far
off. For instan
Richard Rowell <[EMAIL PROTECTED]> writes:
> I'm trying to port our application from MS-SQL to Postgres. We have
> implemented all of our rather complicated application security in the
> database. The query that follows takes a half of a second or less on
> MS-SQL server and around 5 seconds on P
The first thing to check... Did you do a recent VACUUM ANALYZE? This
updates all the statistics. There are a number of places where it says
"rows=1000" which is usually the "I have no idea, let me guess 1000".
Also, there are a number of places where the estimates are pretty far
off. For instance:
Richard Rowell wrote:
I'm trying to port our application from MS-SQL to Postgres. We have
implemented all of our rather complicated application security in the
database. The query that follows takes a half of a second or less on
MS-SQL server and around 5 seconds on Postgres. My concern is that
* Richard Rowell ([EMAIL PROTECTED]) wrote:
> I have included an EXPLAIN ANALYZE, relevant table counts, and relevant
> indexing information. If anyone has any suggestions on how to improve
> performance TIA!
Just a thought- do the UNION's actually have to be union's or would
having them be
I'm trying to port our application from MS-SQL to Postgres. We have
implemented all of our rather complicated application security in the
database. The query that follows takes a half of a second or less on
MS-SQL server and around 5 seconds on Postgres. My concern is that this
data set is rathe
