On Dec 26, 2007 7:36 PM, Chris Hoover <[EMAIL PROTECTED]> wrote:
> Is anyone running their production PostgreSQL server on the RHEL Cluster
> software? If so, how is it working for you? My linux admin is looking at
> trying to increase the robustness of our environment and wanting to try and
> e
On 9/12/07, Scott Marlowe <[EMAIL PROTECTED]> wrote:
>
> On 9/12/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > Try a REINDEX. VACUUM FULL is especially hard on the indexes, and it's
> > > easy for them to seriously bloat.
> >
> > Reindex is done everyday after VACUUM FULL VERBOSE ANALYZE
On 9/4/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Hello everyone:
>
>I wanted to ask you about how the VACUUM ANALYZE works. is it possible
> that something can happen in order to reset its effects forcing to execute
> the VACUUM ANALYZE comand again?
Yes, lots of modifications (IN
On 8/31/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
>
> Pallav Kalva wrote:
> > Tom Lane wrote:
>
> >> Probably represents freezing of old tuples, which is a WAL-logged
> >> operation as of 8.2. Is it likely that the data is 200M transactions
> >> old?
> >>
> > If nothing changed on these tables
On 8/24/07, Anton <[EMAIL PROTECTED]> wrote:
>
> Hi.
>
> I just created partitioned table, n_traf, sliced by month
> (n_traf_y2007m01, n_traf_y2007m02... and so on, see below). They are
> indexed by 'date_time' column.
> Then I populate it (last value have date 2007-08-...) and do VACUUM
> ANALYZE
On 6/20/07, Tom Lane <[EMAIL PROTECTED]> wrote:
There's no obvious reason for the previous query to be so slow, unless
you've got horrendously slow or overloaded disk hardware. What sort of
machine is this anyway, and was it doing any other work at the time?
Granted it is doing other work
On 6/20/07, Tom Lane <[EMAIL PROTECTED]> wrote:
"Mikko Partio" <[EMAIL PROTECTED]> writes:
> Adding a new index does not speed up the query (although the planner
decides
> to use the index):
Hm. Lots of dead rows maybe? What's your vacuuming policy?
On 6/20/07, Tom Lane <[EMAIL PROTECTED]> wrote:
"Mikko Partio" <[EMAIL PROTECTED]> writes:
> Index Scan using tbl_20070601_pkey on tbl_20070601 t1
> (cost=0.00..365.13rows=13 width=137) (actual time=
> 120.83..10752.64 rows=539 loops=1)
>Index Cond: ((v
Hello group
I have a problem with a simple index scan using the primary key of a table
taking too long.
Relevant facts:
pg version 7.3.4 (yeah very old, we are upgrading asap)
postgresql.conf:
shared_buffers = 25000
random_page_cost = 2
effective_cache_size = 20
sort_mem = 2
Table:
db=
