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 pr
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 b
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
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 Debi
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
http://www.commandpro
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 for
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.
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
> http://developer.postgresql.org/pgdocs/postgre
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
> 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 (p
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 se
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 t
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 of
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 an
> 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 pgs
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 mid
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
--
q
> 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 wou
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?
_
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
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, s
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
22 matches
Mail list logo
