On L, 2005-09-24 at 20:25 -0700, Joshua D. Drake wrote:
Actually this also probably would not gain you much in 8.1
as vacuum in theory is already dealing with itself.
Interesting. Could you explain it in a more detailed way ?
How does vacuum deal with itself in 8.1 ?
Also, would it be
On L, 2005-09-24 at 19:32 -0500, Jim C. Nasby wrote:
On Sat, Sep 24, 2005 at 07:21:19PM -0400, Tom Lane wrote:
Of course maybe a better question is why we even limit based on the
number of relations...
Shared memory is fixed-size.
True, but can't the fixed memory required
On L, 2005-09-24 at 18:59 -0500, Jim C. Nasby wrote:
I have a client with a database that contains 4000 relations according
to vacuum verbose, and \d in psql is painfully slow. In particular...
- Seq Scan on pg_class c (cost=0.00..2343.09 rows=6124 width=73)
(actual
On Sat, Sep 24, 2005 at 07:18:16PM -0400, Bruce Momjian wrote:
Well, it seems we are going to have to fix it somehow for 8.1. It is
not crashing here so I can't work up a patch. Can you submit a minimal
fix for 8.1? Thanks.
Ah, it would only happen if your encoding was UTF-8 since that's
Martijn van Oosterhout wrote:
I rely on the signal handler that the JVM uses for page-faults (which a
stack overflow generally amounts to) and fpe exeptions so I know that
they will generate java exceptions in a controlled way (which I in turn
translate to elog(ERROR) on the main thread).
Hannu Krosing wrote:
On L, 2005-09-24 at 20:25 -0700, Joshua D. Drake wrote:
Actually this also probably would not gain you much in 8.1
as vacuum in theory is already dealing with itself.
Interesting. Could you explain it in a more detailed way ?
How does vacuum deal with itself in
Hannu Krosing [EMAIL PROTECTED] writes:
Perhaps VACUUM could send some statistics after each N pages and this
would then be available through something similar to pg_statistics
table.
Why not just have it send some text to be displayed in the current
command field of pg_stat_activity? The
Inserting into a time field with limited precision rounds off, which
is good except for this case:
regression=# select '23:59:59.9'::time(0);
time
--
24:00:00
(1 row)
This is bad because:
regression=# select '24:00:00'::time(0);
ERROR: date/time field value out of range:
On Fri, 2005-09-23 at 11:31 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Since we know the predicted size of the sort set prior to starting the
sort node, could we not use that information to allocate memory
appropriately? i.e. if sort size is predicted to be more than twice
On Fri, 2005-09-23 at 12:48 -0400, Ron Peacetree wrote:
I have some indications from private tests that very high memory settings
may actually hinder performance of the sorts, though I cannot explain that
and wonder whether it is the performance tests themselves that have issues.
Hmmm.
Hi,
I basically have a functional version for aligned output, examples at
the bottom of this email. It handles multiline data values and
multiline headers. However, there are some areas where I could use some
input.
1. To be able to control the spacing, psql now has to be very careful
about its
Bruce Momjian wrote:
Simon's page is in the patches queue. What would you like changed,
exactly?
I'm not going to have time to comment on this any time soon, sorry :( ..
I guess I will try to look at it for 8.2.
-O
---(end of broadcast)---
TIP
12 matches
Mail list logo
