At 05:24 02/11/2009, you wrote:
>The only reason I can think of for wanting to compress very small
>datums is if you have a gajillion of them, they're highly
>compressible, and you have extra CPU time coming out of your ears. In
>that case - yeah, you might want to think about pre-compressing the
Thank you all for the fast responses!
I changed the delete's schedule from daily to hourly and I will let you
know the result. This seems to be the most promising step.
The next one is tuning 'max_fsm_pages'.
Increasing max_fsm_pages can be also helpful, but I've read that
'vacuum verbose ...' wi
Hi Hi all,
I have now readed many many forums and tried many different solutions and I
am not getting good performance to database. My server is Debian linux, with
4gb ram, there is also java application and I am giving to that 512mb
(JAVA_OPTS) memory. In database there is now like 4milj rows. Wh
On Mon, Nov 2, 2009 at 2:16 PM, Grant Masan wrote:
> Hi Hi all,
>
> I have now readed many many forums and tried many different solutions and I
> am not getting good performance to database. My server is Debian linux, with
> 4gb ram, there is also java application and I am giving to that 512mb
>
Grant Masan wrote:
Hi Hi all,
I have now readed many many forums and tried many different solutions
and I am not getting good performance to database. My server is Debian
linux, with 4gb ram, there is also java application and I am giving to
that 512mb (JAVA_OPTS) memory. In database there is
I would recommend (if at all possible) to partition the table and drop
the old partitions when not needed. This will guarantee the space
free-up without VACUUM overhead. Deletes will kill you at some point
and you dont want too much of the VACUUM IO overhead impacting your
performance.
On Mon, Nov
On Mon, Nov 2, 2009 at 7:50 AM, Peter Meszaros wrote:
> Increasing max_fsm_pages can be also helpful, but I've read that
> 'vacuum verbose ...' will issue warnings if max_fsm_pages is too small.
> I've never seen such messag, this command is either run and finish or
> goes to an endless loop as it
Tom Lane wrote:
> Any sane text search application is going to try to filter out
> common words as stopwords; it's only the failure to do that that's
> making this run slow.
Imagine a large table with a GIN index on a tsvector. The user wants
a particular document, and is sure four words are
"Kevin Grittner" writes:
> Tom Lane wrote:
>> Any sane text search application is going to try to filter out
>> common words as stopwords; it's only the failure to do that that's
>> making this run slow.
> I'd rather have the index used for the selective test, and apply the
> remaining tests to
