Alex,
1. The error your report looks like a bug. Is there any more
information in the log? How much memory are you giving to Geoserver?
I will attach the relevant log info below (my log settings are the
default).
I didn't give additional memory to Geoserver. After adding '-Xmx512m' in
the startup.sh file, it took about 1hr 20 min for my map to display.
The Postgis table is pretty big--the INSERT statements alone took about
120MB in an ASCII file.
2. The way WMS and WFS handle <filters> are different.
For WFS, they do what you want them to do -- they always pass the
filter off to the datastore. That means it gets converted into the SQL
WHERE clause.
For WMS, it handles <filters> differently because there could be
multiple filters and else clause (they renderer features that were not
caught by any of the other rules).
So, it makes a request for all the features that intersect the view
rectangle. It also makes a set of Rules that are valid for the current
scale range. The main loop looks like this:
For each Feature in the view rectangle (Datastore processes this)
For each Rule (all handled by java)
IF the Feature satisfies the <Filter> render it
If no Rules were 'hit', then render with the <Else> rule
I see. So far my ideas to speed this up are:
1) Dynamically create a a view in postgis based on a selected option on my
web page client.
This is an ugly workaround. For example, what if there are 2
simultaneous requests for creating a view?
2) Somehow use a RemoteOWS layer, which filters the data in the postgis
table. This didn't appear to work,
since all records were retrieved once again.
What I need to accomplish is very simple. Basically, my table contains a
list of MULTISTRING geometries.
Based on a filter in an SLD_BODY, I need to pluck out a single row, where
the criteria in the filter will match a distinct value:
<Filter>
<PropertyIsEqualTo>
<PropertyName>tiff_name</PropertyName>
<Literal>O3_00_00</Literal>
</PropertyIsEqualTo>
</Filter>
Also, one way to make this faster, Alex, would be create a view based on
your query. Then simply call for the view in the getmap, rather than
the source table.
Of course, this will only work if there are a small number of values for
the discriminating attribute in your query, since you don't want to
create 500 views or something.
--saul
Thank you Saul. I've already thought of that--It's a good workaround and
has worked for me well (until now).
The problem here is that the view would have to be created based on a
user-selected option from a web page.
Any more ideas on how to accomplish this, without selecting everything
in the table prior to display (ala WFS GetFeature filter)?
I would love to be told what I am doing wrong here.
Pointers and the time you took to read this are greatly appreciated 
Alex