Tom Lane wrote:
[EMAIL PROTECTED] writes:
2) As i had a very large pg_largeogject, i deleted rows e now i have a
clean, small table.
The table is empty but its index pg_largeogject_loid_pn_index lasts
to retain a lot of bytes.
REINDEX should fix this.
Is REI
Simon Riggs wrote:
> Situation I thought I saw was:
>
> - copy away current partial filled xlog N
> - xlog N fills, N+1 starts
> - xlog N+1 fills, N+2 starts
> - copy away current partial filled xlog: N+2 (+10 secs later)
>
> i.e. if time to fill xlog (is ever) < time to copy away current xlog,
> t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
On Fri, 22 Oct 2004, Doug Y wrote:
I'm curious if I would see any specific benefit from compiling Postgres from
scratch vs. using an RPM supplied by the distribution?
Remembering that we can build our own RPMS using SRPMS, I've always
believed tha
On Fri, Oct 22, 2004 at 11:04:04 -0400,
Doug Y <[EMAIL PROTECTED]> wrote:
> Hello,
> I'm curious if I would see any specific benefit from compiling
> Postgres from scratch vs. using an RPM supplied by the distribution?
> We're currently using 7.4.2 from an RPM on SuSE 9.0 Pro. I'd guess RPMs
On Fri, 2004-10-22 at 17:44, Gaetano Mendola wrote:
> | Gaetano - skim-reading your script, how do you handle the situation when a
> | new xlog file has been written within 10 seconds? That way the current file
> | number will have jumped by 2, so when your script looks for the "Last wal"
> | using
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Simon Riggs wrote:
|>Gaetano Mendola wrote
|>Postgres can help this process, as suggested by Tom creating a
|
| pg_current_wal()
|
|>or even better having two new GUC parameters: archive_current_wal_command
|
| and
|
|>archive_current_wal_delay.
|
|
| O
Hello,
I'm curious if I would see any specific benefit from compiling
Postgres from scratch vs. using an RPM supplied by the distribution?
We're currently using 7.4.2 from an RPM on SuSE 9.0 Pro. I'd guess RPMs
are usually configured with the least common denominator in mind. All
the software
Stephan Szabo wrote:
On Fri, 22 Oct 2004, Joe Maldonado wrote:
Scott Marlowe wrote:
On Thu, 2004-10-21 at 10:49, Joe Maldonado wrote:
Scott Marlowe wrote:
On Wed, 2004-10-20 at 08:17, Joe Maldonado wrote:
Hello all,
I have created users for which I have restric
Anshaj <[EMAIL PROTECTED]> writes:
> when I try to do a query like
> explain analyze select * from foo where snumber > 1000;
> It do a sequence scan on table.
One-sided inequalities are frequently not selective enough to justify an
indexscan. A rule of thumb is that if the WHERE selects more than
On Fri, 22 Oct 2004, Joe Maldonado wrote:
> Scott Marlowe wrote:
>
> >On Thu, 2004-10-21 at 10:49, Joe Maldonado wrote:
> >
> >
> >>Scott Marlowe wrote:
> >>
> >>
> >>
> >>>On Wed, 2004-10-20 at 08:17, Joe Maldonado wrote:
> >>>
> >>>
> >>>
> >>>
> Hello all,
> I have created users for
Scott Marlowe wrote:
On Thu, 2004-10-21 at 10:49, Joe Maldonado wrote:
Scott Marlowe wrote:
On Wed, 2004-10-20 at 08:17, Joe Maldonado wrote:
Hello all,
I have created users for which I have restricted access to SELECT
from a set of tables, this works :)
But when
Please do not post new topic as reply's to unrelated threads!!
On Friday 22 October 2004 02:10, Anshaj wrote:
> Dear group,
>
> I have a table foo
> anshajdb=# \d foo
>Table "public.foo"
> Column | Type| Modifiers
> -+---+---
>
> Gaetano Mendola wrote
> Postgres can help this process, as suggested by Tom creating a
pg_current_wal()
> or even better having two new GUC parameters: archive_current_wal_command
and
> archive_current_wal_delay.
OK, we can modify the archiver to do this as well as the archive-when-full
function
13 matches
Mail list logo
