Pavan Deolasee wrote:
On Fri, Apr 4, 2008 at 11:10 AM, Tom Lane [EMAIL PROTECTED] wrote:
The
policy of this project is that we only put nontrivial bug fixes into
back branches, and I don't think this item qualifies ...
Got it. I will submit a patch for HEAD.
Thanks,
As I
Pavan Deolasee [EMAIL PROTECTED] writes:
Please see the attached patch. One change I made is to hold the SHARE lock
on the page while ANALYZE is reading tuples from it. I thought it would
be a right thing to do instead of repeatedly acquiring/releasing the lock.
I've applied a
On Thu, Apr 3, 2008 at 10:02 PM, Tom Lane [EMAIL PROTECTED] wrote:
I've applied a modified/extended form of this patch for 8.3.2.
Thanks. I had another concern about VACUUM not reporting DEAD line
pointers (please see up thread). Any comments on that ?
Thanks,
Pavan
--
Pavan Deolasee
Pavan Deolasee [EMAIL PROTECTED] writes:
Thanks. I had another concern about VACUUM not reporting DEAD line
pointers (please see up thread). Any comments on that ?
If you want to work on that, go ahead, but I wanted it separate because
I didn't think it merited back-patching. It's strictly
On Thu, Apr 3, 2008 at 10:39 PM, Tom Lane [EMAIL PROTECTED] wrote:
Pavan Deolasee [EMAIL PROTECTED] writes:
Thanks. I had another concern about VACUUM not reporting DEAD line
pointers (please see up thread). Any comments on that ?
If you want to work on that, go ahead
Ok. I would do
Pavan Deolasee [EMAIL PROTECTED] writes:
On Thu, Apr 3, 2008 at 10:39 PM, Tom Lane [EMAIL PROTECTED] wrote:
I didn't think it merited back-patching. It's strictly cosmetic in
terms of being about what VACUUM VERBOSE prints, no?
Umm.. Whatever we decide on the fix, I think we should backpatch
On Fri, Apr 4, 2008 at 11:10 AM, Tom Lane [EMAIL PROTECTED] wrote:
The
policy of this project is that we only put nontrivial bug fixes into
back branches, and I don't think this item qualifies ...
Got it. I will submit a patch for HEAD.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB
On Tue, Apr 1, 2008 at 1:22 AM, Tom Lane [EMAIL PROTECTED] wrote:
Please do --- I have a lot of other stuff on my plate.
Please see the attached patch. One change I made is to hold the SHARE lock
on the page while ANALYZE is reading tuples from it. I thought it would
be a right thing to do
On Tue, 2008-04-01 at 13:07 +0530, Pavan Deolasee wrote:
Please see the attached patch. One change I made is to hold the SHARE lock
on the page while ANALYZE is reading tuples from it. I thought it would
be a right thing to do instead of repeatedly acquiring/releasing the lock.
ANALYZE is a
Please do --- I have a lot of other stuff on my plate.
Please see the attached patch. One change I made is to hold the SHARE lock
on the page while ANALYZE is reading tuples from it. I thought it would
be a right thing to do instead of repeatedly acquiring/releasing the lock.
I have
Simon Riggs [EMAIL PROTECTED] writes:
On Tue, 2008-04-01 at 10:22 -0400, Tom Lane wrote:
In the fourth, if we actually believed this was a problem we'd
need to redesign VACUUM too, as it does the same thing.
VACUUM waits until nobody else has the buffer pinned, so lock contention
is much
Simon Riggs [EMAIL PROTECTED] writes:
On Tue, 2008-04-01 at 13:07 +0530, Pavan Deolasee wrote:
Please see the attached patch. One change I made is to hold the SHARE lock
on the page while ANALYZE is reading tuples from it. I thought it would
be a right thing to do instead of repeatedly
On Tue, 2008-04-01 at 10:22 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Tue, 2008-04-01 at 13:07 +0530, Pavan Deolasee wrote:
Please see the attached patch. One change I made is to hold the SHARE lock
on the page while ANALYZE is reading tuples from it. I thought it
Tom Lane [EMAIL PROTECTED] writes:
Simon Riggs [EMAIL PROTECTED] writes:
On Tue, 2008-04-01 at 13:07 +0530, Pavan Deolasee wrote:
Please see the attached patch. One change I made is to hold the SHARE lock
on the page while ANALYZE is reading tuples from it. I thought it would
be a right
I have a table with about 15 million rows which is constantly having
tuples added to the head and deleted in blocks from the tail to maintain
the size. The dead tuple count in pg_stat_user_tables tracks the deleted
rows fairly accurately until an auto-ANALYZE is done in the background
at which
On Mon, Mar 31, 2008 at 1:33 PM, Stuart Brooks [EMAIL PROTECTED] wrote:
I have a table with about 15 million rows which is constantly having
tuples added to the head and deleted in blocks from the tail to maintain
the size. The dead tuple count in pg_stat_user_tables tracks the deleted
rows
Pavan Deolasee [EMAIL PROTECTED] writes:
Seems like the redirected-dead line pointers are playing spoil-sport here.
In this particular example, the deleted tuples may get truncated to
redirected-dead line pointers. Analyze would report them as empty
slots and not as dead tuples. So in the
On Mon, Mar 31, 2008 at 9:02 PM, Tom Lane [EMAIL PROTECTED] wrote:
[ Please see if you can stop using the redirected dead terminology ]
Apologies, will keep that in mind. Seems like a hang-over from the past :-)
Yeah, I think I agree. The page pruning code is set up so that changing
a
Pavan Deolasee [EMAIL PROTECTED] writes:
On Mon, Mar 31, 2008 at 9:02 PM, Tom Lane [EMAIL PROTECTED] wrote:
It looks like there's no trivial way to get ANALYZE to do things that
way, though. heap_release_fetch() doesn't distinguish a DEAD line
pointer from an unused or redirected one. But in
19 matches
Mail list logo
