Mark Roghelia writes:
> Unfortunately, I've recently upgraded to 8.3 and found that selecting
> a single column from this view has now become as slow as selecting all
> of them.
Without specifics there's really no way to answer this.
regards, tom lane
--
Sent via pg
I've got an application that pulls stock information from the web and
performs a bunch of calculations on them. There is a "stock" table
and then for convenience I've got a view called "stock_calculations".
This view is defined as a stock id column coupled with 30-some
calculated column
Greg Smith wrote:
On Tue, 10 Feb 2009, justin wrote:
Not to be overly nick picking where is the version called out that it
applies to. Stating Older version is vague
It's at the bottom of the document. I just updated the "Performance
Optimization" page to reflect that. One of those things
On Tue, 10 Feb 2009, justin wrote:
Not to be overly nick picking where is the version called out that it applies
to. Stating Older version is vague
It's at the bottom of the document. I just updated the "Performance
Optimization" page to reflect that. One of those things I keep meaning to
Greg Smith wrote:
On Tue, 10 Feb 2009, justin wrote:
http://www.varlena.com/GeneralBits/Tidbits/annotated_conf_e.html
checkpoint_segments
Maximum distance between automatic WAL checkpoints, in log file
segments (each
segment is normally 16 megabytes).
Increase these settings if your database
On Tue, 10 Feb 2009, justin wrote:
http://www.varlena.com/GeneralBits/Tidbits/annotated_conf_e.html
checkpoint_segments
Maximum distance between automatic WAL checkpoints, in log file segments (each
segment is normally 16 megabytes).
Increase these settings if your database has lots of large ba
checkpoint_segments
Maximum distance between automatic WAL checkpoints, in log file
segments (each segment is normally 16 megabytes).
Increase these settings if your database has lots of large batch writes
to decrease the frequency of checkpoints (and thus lower disk
activity). Decrease them
On Tue, Feb 10, 2009 at 9:09 PM, Tom Lane wrote:
> Rajesh Kumar Mallah writes:
>> On Tue, Feb 10, 2009 at 6:36 PM, Robert Haas wrote:
>>> I'm guessing that the problem is that the selectivity estimate for
>>> co_name_vec @@ to_tsquery('plastic&tubes') is not very good, but I'm
>>> not real famil
Rajesh Kumar Mallah writes:
> On Tue, Feb 10, 2009 at 6:36 PM, Robert Haas wrote:
>> I'm guessing that the problem is that the selectivity estimate for
>> co_name_vec @@ to_tsquery('plastic&tubes') is not very good, but I'm
>> not real familiar with full text search, so I'm not sure whether
>> th
>>> Wei Yan wrote:
> Our queries are extremely slow only after db server reboot
> Any suggestion on how to tackle the problem?
Others have addressed how you can try to prime your cache after a
reboot, so I'll mention the 800 pound gorilla sitting in the corner.
I suggest you don't reboot as
> Can't use an undefined value as an ARRAY reference at
> /usr/lib/perl5/site_perl/5.8.8/Test/Parser/Dbt2.pm line 521.
>
> Can someone please give inputs to resolve this issue? Any help on this will
> be appreciated.
519 sub transactions {
520 my $self = shift;
521 return @{$self->{data}->
Dear Robert,
thanks for ur interest. Our server was too loaded
what i posted my last observation, now the
other explain analyze can also be run and i am posting
both the result , as you can see latter is 55ms versus
3000 ms .
explain analyze select lead_id from general.trade_leads join
general.pr
On Tue, Feb 10, 2009 at 5:31 AM, Rajesh Kumar Mallah
wrote:
> I have a query in which two huge tables (A,B) are joined using an indexed
> column and a search is made on tsvector on some column on B. Very limited
> rows of B are expected to match the query on tsvector column.
>
> With default plan
Hi All,
I am getting following error while conducting DBT2 tests on PostgreSQL.There
is no error on driver side as such. After completion of test it is giving
problem in generating reports scripts:
Please find the error below:
waiting for server to shut down done
server stopped
server startin
On Mon, 9 Feb 2009, justin wrote:
Well then we have conflicting instructions in places on wiki.postgresql.org
which links to this
http://www.varlena.com/GeneralBits/Tidbits/annotated_conf_e.html
Could you be a little more specific as to which sections conflict?
Matthew
--
The only secure com
Hi ,
I have a query in which two huge tables (A,B) are joined using an indexed
column and a search is made on tsvector on some column on B. Very limited
rows of B are expected to match the query on tsvector column.
With default planner settings the query takes too long ( > 100 secs) , but
with h
16 matches
Mail list logo
