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 mentio
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
EnterpriseD
"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 shoul
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
"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 strictl
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:
> 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 modified/e
On Thu, Apr 3, 2008 at 4:34 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
>
> The right way seems to be to treat our own insertions as live during
> ANALYZE, but then subtract off our own pending insertions from the
> live-tuples count sent to the stats collector. pgstat_report_analyze()
> can hand
I wrote:
> ... What I propose therefore
> is combining this patch with my older one so that ANALYZE counts
> according to the following rules:
> REDIRECT line pointer:ignore
> DEAD line pointer:count as dead
> HEAPTUPLE_LIVE tuple: count as live, include in stat
"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.
Bruce pointed out to me o
"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
>>
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
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 thoug
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
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
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
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
"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
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 chan
"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 t
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
>
21 matches
Mail list logo
