Dear group,
I have a table foo
anshajdb=# \d foo
Table public.foo
Column | Type| Modifiers
-+---+---
snumber | numeric(18,0) |
test| character varying |
Indexes:
snum_idx btree (snumber)
when I try to do a query
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
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
-+---+---
snumber |
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
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 restricted access to SELECT
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 one
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
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
-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.
|
|
| OK,
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 head
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
are
-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
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,
then you
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
14 matches
Mail list logo
