On Thu, May 01, 2008 at 05:12:52PM -0700, fschmidt wrote:
An implementation of clustering without locking would start by comparing the
index to the table from the beginning to find the first mismatch. Rows
before the mismatch are fine, and can be left alone. From here on, go
through the
On Fri, May 2, 2008 at 9:12 AM, fschmidt [EMAIL PROTECTED] wrote:
An implementation of clustering without locking would start by comparing the
index to the table from the beginning to find the first mismatch. Rows
before the mismatch are fine, and can be left alone. From here on, go
Hi,
I think to print PostgreSQL logo on our company brochure. I think it is
permissible. Is not so? Is there a high resolution logo somewhere?
thanks
Sanjay
_
Watch hottest Bollywood videos, clips, movie tailors, star interviews,
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Using 8.3.1
No matter what I try I've never seen any evidence that autovacuum runs on my
system.
I set
autovacuum_vacuum_threshold = 50
Then run a process to do updates on a table, shouldn't autovacuum kick in after
50 updates?
Huh? If I'm understanding you correctly you'll end up with rows in
order, but with a really big hole in the middle of the table. I'm not
sure if that qualifies as clusters.
That's why he said vacuum when done. Anyway, I'm not sure that a big
*contiguous* hole in the middle of the table would
Wouldn't new / updated tuples just get put in the hole, fairly rapidly
un-clustering the table again?
How is that different than putting them in newly-allocated space at the end
of the table?
--
Scott Ribe
[EMAIL PROTECTED]
http://www.killerbytes.com/
(303) 722-0567 voice
--
Sent via
On Fri, May 02, 2008 at 03:32:29PM +0530, Sanjaya Kumar Patel wrote:
I think to print PostgreSQL logo on our company brochure. I think it is
permissible. Is not so? Is there a high resolution logo somewhere?
try here:
http://pgfoundry.org/docman/?group_id=189
best regards,
depesz
--
Scott Ribe wrote:
Huh? If I'm understanding you correctly you'll end up with rows in
order, but with a really big hole in the middle of the table. I'm not
sure if that qualifies as clusters.
That's why he said vacuum when done. Anyway, I'm not sure that a big
*contiguous* hole in the
Hi,
On some corner cases our database servers starts to use from swap space
and that totally makes PostgreSQL (or any other I/O bound application)
to fall upon its knees. In our current structure, responsiveness has the
highest priority and thus it is ok for us to cancel queries at that
instant
Glyn Astill a écrit :
Using 8.3.1
No matter what I try I've never seen any evidence that autovacuum runs on my
system.
I set
autovacuum_vacuum_threshold = 50
Then run a process to do updates on a table, shouldn't autovacuum kick in after
50 updates?
Nope, it also depends on the number
Scott Ribe [EMAIL PROTECTED] writes:
Huh? If I'm understanding you correctly you'll end up with rows in
order, but with a really big hole in the middle of the table. I'm not
sure if that qualifies as clusters.
That's why he said vacuum when done.
Huh? A plain vacuum wouldn't fix that; a
On Fri, May 02, 2008 at 05:46:53PM +0300, Volkan YAZICI wrote:
In our current structure, responsiveness has the
highest priority and thus it is ok for us to cancel queries at that
instant and re-initiate connections. To achieve this effect, I started
to turn swap space off on some of the
Huh? A plain vacuum wouldn't fix that; a vacuum full would close up the
hole, but (a) it'd not preserve the row ordering, and (b) it'd take an
exclusive lock.
OK.
--
Scott Ribe
[EMAIL PROTECTED]
http://www.killerbytes.com/
(303) 722-0567 voice
--
Sent via pgsql-general mailing list
Aha thanks!
So the amount of dead tuples has to satisfy autovacuum_vacuum_scale_factor AND
autovacuum_vacuum_threshold for it to kick off the autovacuum process!
I set autovacuum_vacuum_scale_factor to 0.02 and off it fired vacuuming
everything :-)
- Original Message
From: Guillaume
On Thu, May 1, 2008 at 10:27 PM, Tom Lane [EMAIL PROTECTED] wrote:
Maybe I'm some crazy, radical DBA, but I've never had a version of
pgsql get EOLed out from underneath me.
Just for fun, I did a bit of digging in the release notes
On Fri, May 02, 2008 at 09:18:39AM -0700, Rob Wultsch wrote:
Not really Postgres's problem, but for whatever its worth if I do the
following on Debian stable:
$apt-get install postgresql
I get 7.4 . When I install Debian I generally expect the software to
be supported for a long time.
Andrew Sullivan wrote:
On Fri, May 02, 2008 at 09:18:39AM -0700, Rob Wultsch wrote:
Not really Postgres's problem, but for whatever its worth if I do the
following on Debian stable:
$apt-get install postgresql
I get 7.4 . When I install Debian I generally expect the software to
be supported
On Fri, May 02, 2008 at 09:57:58PM +0200, Tino Wildenhain wrote:
apt-get install postgresql-8.1 gives you 8.1 in etch (stable)
in addition to 7.4.
Huh. Debian gets more inscrutable every time I fail to look.
A
--
Andrew Sullivan
[EMAIL PROTECTED]
+1 503 667 4564 x104
On Fri, 2 May 2008 15:48:13 -0400 Andrew Sullivan wrote:
On Fri, May 02, 2008 at 09:18:39AM -0700, Rob Wultsch wrote:
Not really Postgres's problem, but for whatever its worth if I do the
following on Debian stable:
$apt-get install postgresql
I get 7.4 . When I install Debian I
Scott Ribe wrote:
Wouldn't new / updated tuples just get put in the hole, fairly rapidly
un-clustering the table again?
How is that different than putting them in newly-allocated space at the end
of the table?
It isn't, I just wasn't thinking straight.
This is probably a stupid idea
Craig Ringer [EMAIL PROTECTED] writes:
So ... is this crazy? Concurrently clustering the table by moving each
record *twice*, in batches, with pauses to allow old versions to cease
being visible by any live transaction? Or can it actually work?
It seems to me you'd have a pretty horrid bloat
Tom Lane wrote:
Craig Ringer [EMAIL PROTECTED] writes:
So ... is this crazy? Concurrently clustering the table by moving each
record *twice*, in batches, with pauses to allow old versions to cease
being visible by any live transaction? Or can it actually work?
It seems to me you'd have a
23 matches
Mail list logo
