Jan Wieck wrote:
> Tom Lane wrote:
>
> > Jan Wieck <[EMAIL PROTECTED]> writes:
> >> Okay, my proposal would be to have a VACUUM mode where it tells the
> >> buffer manager to only return a page if it is already in memory, and
> >> some "not cached" if it would have to read it from disk, and simp
After a long battle with technology,[EMAIL PROTECTED] (Vivek Khera), an earthling,
wrote:
>> "TL" == Tom Lane <[EMAIL PROTECTED]> writes:
>
> TL> Just nice'ing the VACUUM process is likely to be counterproductive
> TL> because of locking issues (priority inversion). Though if anyone cares
> T
After a long battle with technology,[EMAIL PROTECTED] (Jan Wieck), an earthling, wrote:
> Tom Lane wrote:
>> Jan Wieck <[EMAIL PROTECTED]> writes:
>>
>>> What about a little hint to the buffer management that if it has to
>>> evict another buffer to physically read this one (meaning the
>>> buffer
Vivek Khera wrote:
> > "BM" == Bruce Momjian <[EMAIL PROTECTED]> writes:
>
>
> BM> Hold --- a non-FULL vacuum is taking 6+ hours on two tables? That seems
> BM> impossible.
>
> Well, did I mention I'm saturating my disk I/O bandwidth at the same
> time with other queries? ;-)
But six hours
> "BM" == Bruce Momjian <[EMAIL PROTECTED]> writes:
>>
>> Well, did I mention I'm saturating my disk I/O bandwidth at the same
>> time with other queries? ;-)
BM> But six hours. It is my understanding that a sequential scan is roughly
BM> the same load as a non-FULL vacuum. Are you saying
> "TL" == Tom Lane <[EMAIL PROTECTED]> writes:
TL> Just nice'ing the VACUUM process is likely to be counterproductive
TL> because of locking issues (priority inversion). Though if anyone cares
TL> to try it on a heavily-loaded system, I'd be interested to hear the
TL> results...
tried it onc
Bruce Momjian wrote:
Jan Wieck wrote:
Manfred Koizar wrote:
> On Thu, 21 Aug 2003 21:10:34 +0530, "Shridhar Daithankar"
> <[EMAIL PROTECTED]> wrote:
>>Point I am trying to make is to tune FSM and autovacuum frequency
>>such that you catch all the dead tuples in RAM
>
> You might be able to catch
Jan Wieck wrote:
> Manfred Koizar wrote:
> > On Thu, 21 Aug 2003 21:10:34 +0530, "Shridhar Daithankar"
> > <[EMAIL PROTECTED]> wrote:
> >>Point I am trying to make is to tune FSM and autovacuum frequency
> >>such that you catch all the dead tuples in RAM
> >
> > You might be able to catch the pag
Initial beta release of plPHP http://www.postgresql.org/news/143.html
On Tue, 2003-08-19 at 10:46, David Siebert wrote:
I learned MySQL then went on to Postgres. I chose postgres for my in
house project just because of the row locking and transactions. Looking
back I could have used MySQL.
Claudio Lapidus wrote:
Bruno Wolff III wote:
On Fri, Aug 22, 2003 at 12:17:41 +0530,
Shridhar Daithankar <[EMAIL PROTECTED]> wrote:
>
> Idea of autovacuum is to reduce load on vacuum full. If you set
shared_buffers
> higher and FSM properly for he update/delete load, autovacuum is
expected to
>
On Fri, 22 Aug 2003, Claudio Lapidus wrote:
> Bruno Wolff III wote:
> > On Fri, Aug 22, 2003 at 12:17:41 +0530,
> > Shridhar Daithankar <[EMAIL PROTECTED]> wrote:
> > >
> > > Idea of autovacuum is to reduce load on vacuum full. If you set
> shared_buffers
> > > higher and FSM properly for he upd
On 22 Aug 2003 at 12:35, Claudio Lapidus wrote:
> Bruno Wolff III wote:
> > On Fri, Aug 22, 2003 at 12:17:41 +0530,
> > Shridhar Daithankar <[EMAIL PROTECTED]> wrote:
> > >
> > > Idea of autovacuum is to reduce load on vacuum full. If you set
> shared_buffers
> > > higher and FSM properly for he
Bruno Wolff III wote:
> On Fri, Aug 22, 2003 at 12:17:41 +0530,
> Shridhar Daithankar <[EMAIL PROTECTED]> wrote:
> >
> > Idea of autovacuum is to reduce load on vacuum full. If you set
shared_buffers
> > higher and FSM properly for he update/delete load, autovacuum is
expected to
> > catch most o
Manfred Koizar wrote:
On Thu, 21 Aug 2003 21:10:34 +0530, "Shridhar Daithankar"
<[EMAIL PROTECTED]> wrote:
Point I am trying to make is to tune FSM and autovacuum frequency
such that you catch all the dead tuples in RAM
You might be able to catch the pages with dead tuples in RAM, but
currently th
On Thu, 21 Aug 2003 21:10:34 +0530, "Shridhar Daithankar"
<[EMAIL PROTECTED]> wrote:
>Point I am trying to make is to tune FSM and autovacuum frequency
>such that you catch all the dead tuples in RAM
You might be able to catch the pages with dead tuples in RAM, but
currently there's no way to kee
What I am pointing out is that this is all the same issue, and that
solutions to the "we can't do priorities because of locking issues" have
existed for many years. I/O is the same as processors, it is a resource
that needs managing. So the intelligence can be made to exist, it just
needs to be mad
On Thu, Aug 21, 2003 at 09:10:34PM +0530, Shridhar Daithankar wrote:
> Well, nothing can help if the database has dead tuples already.
> Sometime somebody has to take time to run vacuum full and/or
> database reload to get a clean state.
But if you have a busy system, you'll have new dead tuples.
On Thu, Aug 21, 2003 at 12:05:28PM -0400, Edmund Dengler wrote:
> Well, if they are locked waiting on vacuum, then vacuum should upgrade
> it's priority to the highest waiting process (priority inheritance).
> This way, vacuum will be running at a priority level equivalent to who is
> waiting on it
Well, if they are locked waiting on vacuum, then vacuum should upgrade
it's priority to the highest waiting process (priority inheritance).
This way, vacuum will be running at a priority level equivalent to who is
waiting on it.
Regards,
Ed
On Thu, 21 Aug 2003, Andrew Sullivan wrote:
> On Wed, A
On 21 Aug 2003 at 11:26, Andrew Sullivan wrote:
> On Thu, Aug 21, 2003 at 08:38:14PM +0530, Shridhar Daithankar wrote:
> > If a database is clean i.e. no dead tuple, an autovacuum daemon with 1 min
> > interval can achieve pretty much same result, isn't it?
>
> But we're talking about the case o
On Thu, Aug 21, 2003 at 08:38:14PM +0530, Shridhar Daithankar wrote:
> If a database is clean i.e. no dead tuple, an autovacuum daemon with 1 min
> interval can achieve pretty much same result, isn't it?
But we're talking about the case of large, busy databases that have
already choked their disk
On 21 Aug 2003 at 11:01, Andrew Sullivan wrote:
> On Thu, Aug 21, 2003 at 03:40:29PM +1000, Martijn van Oosterhout wrote:
> > Given lazy vacuum doesn't hold locks for long periods, it could be
> > an idea to continuously spend 1% of your disk bandwidth on a
> > background vacuum. As for vacuum ful
On 21 Aug 2003 at 10:59, Andrew Sullivan wrote:
> On Wed, Aug 20, 2003 at 05:58:32PM -0400, Tom Lane wrote:
> > Jan Wieck <[EMAIL PROTECTED]> writes:
> > > the LRU chain but rather at it's end? This way a vacuum on a large table
> > > will not cause a complete cache eviction.
> >
> > I think wha
On Wed, Aug 20, 2003 at 11:41:41PM +0200, Karsten Hilbert wrote:
> You mean, like, "nice 19" or so ?
ISTR someone reporting problems with locking on the performance list
from doing exactly that. The problem is that the vacuum back end
might take a lock and then not get any processor time -- in wh
On Thu, Aug 21, 2003 at 03:40:29PM +1000, Martijn van Oosterhout wrote:
> Given lazy vacuum doesn't hold locks for long periods, it could be
> an idea to continuously spend 1% of your disk bandwidth on a
> background vacuum. As for vacuum full, I don't know if you could do
> the same thing.
Assumi
On Wed, Aug 20, 2003 at 05:58:32PM -0400, Tom Lane wrote:
> Jan Wieck <[EMAIL PROTECTED]> writes:
> > the LRU chain but rather at it's end? This way a vacuum on a large table
> > will not cause a complete cache eviction.
>
> I think what we really need is a way to schedule VACUUM's I/O at a lower
What about the use of priority inheritance to deal with the issue of
priority inversion (a standard methodology within the real-time world)?
Then we could have priorities, but still have low priority processes
bumped up if a high level one is waiting on them.
Regards,
Ed
On Wed, 20 Aug 2003, Tom
> it seems to me what would be more useful is an even
> lazier vacuum: something that could be told "clean up as cycles are
> available, but make sure you stay out of the way." Of course, that's
> easy to say glibly, and mighty hard to do, I expect.
You mean, like, "nice 19" or so ?
Karsten
--
G
Andrew Sullivan <[EMAIL PROTECTED]> writes:
>> I disagree. Triggering a vacuum on a db that is nearly saturating the
>> disk bandwidth has a significant impact.
> Vivek is right about this. If your system is already very busy, then
> a vacuum on a largish table is painful.
> I don't actually th
Andrew Sullivan wrote:
On Wed, Aug 20, 2003 at 12:40:03PM -0400, Vivek Khera wrote:
> "BW" == Bruno Wolff, writes:
BW> Also, since at least 7.3, normal vacuums aren't normally going to
BW> affect the performance of your database server that much.
I disagree. Triggering a vacuum on a db that
On Wed, Aug 20, 2003 at 12:40:03PM -0400, Vivek Khera wrote:
> > "BW" == Bruno Wolff, writes:
> BW> Also, since at least 7.3, normal vacuums aren't normally going to
> BW> affect the performance of your database server that much.
>
> I disagree. Triggering a vacuum on a db that is nearly sat
Jan Wieck <[EMAIL PROTECTED]> writes:
> Aah - there is the first bullet hole in my multi-ctid-index-idea. Now
> the question becomes how expensive these tests are (if a normal backend
> can do them at all within reason)?
It's not hugely expensive, IIRC, you just need to make some additional
chec
Tom Lane wrote:
Recall also that "committed deleted" does not mean "safe to remove".
There may still be live transactions that could see the tuple. The
"committed deleted" bit just exists to allow subsequent visitors to the
row to skip one of the more expensive steps in deciding whether they can
Stephan Szabo <[EMAIL PROTECTED]> writes:
> True, but the message being responded to was specifically "if the backend
> were to do the checking for external references upon updating/deleting a
> row".
It's clearly impossible for a backend to remove a row immediately upon
updating/deleting it, sinc
Vivek Khera <[EMAIL PROTECTED]> writes:
> "JW" == Jan Wieck <[EMAIL PROTECTED]> writes:
> JW> remove all the index entries pointing to these ctid's. Your idea is (so
> JW> far) lacking a place where to remember all the single removed rows and I
> JW> assume you're not planning to pay the cost of a
On Wed, 20 Aug 2003, Vivek Khera wrote:
> > "BW" == Bruno Wolff, writes:
>
> >> to see it incremental. This would result in pretty much near zero
> >> internal fragmentation, I think.
>
> BW> Why do you care about about the details of the implementation (rather than
> BW> the performance)?
On Wed, Aug 20, 2003 at 10:31:25AM -0400, Vivek Khera wrote:
> Seriously, how much slower can it be if the backend were to do the
> checking for external references upon updating/deleting a row? The
> cost would be distributed across time as opposed to concentrated at
> once within a vacuum proce
On Wed, Aug 20, 2003 at 10:31:25 -0400,
Vivek Khera <[EMAIL PROTECTED]> wrote:
>
> I care for the performance. And how are you so sure that it was
> faster the way it is now? Are you sure it was not done this way
> because of ease of implementation?
>
> Seriously, how much slower can it be if
> "BW" == Bruno Wolff, writes:
>> to see it incremental. This would result in pretty much near zero
>> internal fragmentation, I think.
BW> Why do you care about about the details of the implementation (rather than
BW> the performance)? If it were faster to do it that way, that's how it wou
On Tue, Aug 19, 2003 at 21:51:14 -0400,
Vivek Khera <[EMAIL PROTECTED]> wrote:
>
> I'm not promoting any change in the MVCC. What I'm saying is that it
> would be really cool if the backend process itself could recognize
> that a row is no longer referenced by any transactions upon
> terminatio
> "MTO" == Matthew T O'Connor <[EMAIL PROTECTED]> writes:
MTO>
MTO> Changing Postgres to perform as mentioned above is non-trivial, it would
MTO> basicially change the entire core of the system. I think this is due to
MTO> the fact that postgres uses a non-overwriting storage manager. This
On Tue, 2003-08-19 at 12:13, Vivek Khera wrote:
> There's a big difference between "noticing that a table needs to be
> vacuumed and running it" and "automatically having the backend free a
> row as soon as we know it is eligible to be (as would normally be
> determined by vacuum)".
Changing Post
On Tuesday 19 August 2003 23:10, scott.marlowe wrote:
> On 19 Aug 2003, Bo Lorentsen wrote:
> > On Tue, 2003-08-19 at 18:17, Vivek Khera wrote:
> > > Since the beginning of time (at least MySQL v3.22) MySQL has silently
> > > ignored the foreign key references in table create statement. Now
> > >
On Tue, 2003-08-19 at 23:10, scott.marlowe wrote:
> So the syntaxes are different, and one is apparently swallowed without
> error or anything, but in fact you have no fks in place.
Thanks, that helped.
/BL
---(end of broadcast)---
TIP 8: explain
On 19 Aug 2003, Bo Lorentsen wrote:
> On Tue, 2003-08-19 at 18:17, Vivek Khera wrote:
>
> > Since the beginning of time (at least MySQL v3.22) MySQL has silently
> > ignored the foreign key references in table create statement. Now
> > that they have foreign key support (version 4.x), do they ho
It's still bolted on. The entire concept that "transactional integrity
is optional" is ludicrous, IMHO. "Integrity" and "optional" are
contradictory.
Obviously you have never voted in a major election ;)
regards, tom lane
---(end of broadcast)---
On Tue, Aug 19, 2003 at 19:17:31 +0530,
Shridhar Daithankar <[EMAIL PROTECTED]> wrote:
>
> Making pgsql-bugs a open to non-subscription but moderated list might be a
> good idea. It really does not matter if a bug gets filed couple of days late
> but having to have subscribe to another list co
On Tuesday 19 August 2003 21:03, Vivek Khera wrote:
> Tops on my wish list is that postgres automatically notice when a row
> is no longer needed (all transactional references to it are gone) and
> 'free' it at that time, rather then needing a special scan to
> determine the row is no longer needed
> "BL" == Bo Lorentsen <[EMAIL PROTECTED]> writes:
BL> Hi ...
BL> I'm trying to convince my boss to use posgresql (I need RI, transactions
BL> and views), but he keeps comparing the project to mysql. Until now, I
BL> found the answers to he's questions on the www.postgresql.org page, but
BL> n
On Tue, 2003-08-19 at 16:20, Lincoln Yeoh wrote:
> Install an application that can use both DBs. Muck around with it. If you
> can't tell the difference, then I'd say go with postgresql - transactions
> isn't bolted on, quite a number of other design wins too. If you can tell
> the difference a
On Tue, 2003-08-19 at 16:03, Tom Lane wrote:
> It's still bolted on. The entire concept that "transactional integrity
> is optional" is ludicrous, IMHO. "Integrity" and "optional" are
> contradictory.
Good point. Also the problem of MyISAM and InnoDB RI :-)
> One thing you should ask about MySQ
Hi,
On Tue, 19 Aug 2003, Lincoln Yeoh wrote:
> AFAIK bugzilla requires mysql (for now).
>
> I've recently installed it and if it can be easily made to work with
> postgresql I'd like to know.
https://bugzilla.redhat.com/bugzilla/index.cgi
Bugzilla News
===
January 1st, 2003
Current Red Hat v
At 03:59 PM 8/19/2003 +0200, Bo Lorentsen wrote:
On Tue, 2003-08-19 at 15:47, Shridhar Daithankar wrote:
> Or have bugzilla setup somewhere. That way the tracking will be hell lot
> visible to outside world..
I agree on this, as it seems messy from outside not to be able to get an
overview of bot
53 matches
Mail list logo
