On Wed, Jun 8, 2011 at 10:45 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Pavan Deolasee pavan.deola...@gmail.com writes:
I first thought that analyze and vacuum can not run concurrently on the
same
table since they take a conflicting lock on the table. So even if we
ignore
the analyze process
On Thu, Jun 9, 2011 at 11:50 AM, Pavan Deolasee pavan.deola...@gmail.comwrote:
Ah, I see. Would there will be benefits if we can do some special handling
for cases where we know that ANALYZE is running outside a transaction block
and that its not going to invoke any user-defined functions ?
On Thu, Jun 9, 2011 at 2:20 AM, Pavan Deolasee pavan.deola...@gmail.com wrote:
Ah, I see. Would there will be benefits if we can do some special handling
for cases where we know that ANALYZE is running outside a transaction block
and that its not going to invoke any user-defined functions ?
I am wondering if we shouldn't be asking ourselves a different
question: why is ANALYZE running long enough on your tables for this
to become an issue? How long is it taking?
The log file attached in the first post has the details; it's taking around 5
mins for the accounts table with
On Thu, Jun 9, 2011 at 10:52 AM, Pavan Deolasee
pavan.deola...@gmail.com wrote:
I am wondering if we shouldn't be asking ourselves a different
question: why is ANALYZE running long enough on your tables for this
to become an issue? How long is it taking?
The log file attached in the first
Robert Haas robertmh...@gmail.com writes:
On Thu, Jun 9, 2011 at 10:52 AM, Pavan Deolasee
pavan.deola...@gmail.com wrote:
I am wondering if we shouldn't be asking ourselves a different
question: why is ANALYZE running long enough on your tables for this
to become an issue? How long is it
On 09-Jun-2011, at 8:29 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Jun 9, 2011 at 10:52 AM, Pavan Deolasee
pavan.deola...@gmail.com wrote:
I am wondering if we shouldn't be asking ourselves a different
question: why is ANALYZE running long
Hi All,
I was running some pgbench tests and observed this phenomenon. This might be
a known issue, but I thought its nevertheless worth mentioning.
Auto-analyze process grabs a MVCC snapshot. If it runs on a very large
table, it may take considerable time and would stop the OldestXmin from
On Jun 8, 2011 1:49 PM, Pavan Deolasee pavan.deola...@gmail.com wrote:
Hi All,
There is a PROC_IN_ANALYZE flag, but we don't seem to be using it
anywhere. Since acquire_sample_rows() returns palloced tuples, can't we let
OldestXmin advance after scanning a page by ignoring procs with the flag
On Wed, Jun 8, 2011 at 9:03 PM, Greg Stark st...@mit.edu wrote:
On Jun 8, 2011 1:49 PM, Pavan Deolasee pavan.deola...@gmail.com wrote:
Hi All,
There is a PROC_IN_ANALYZE flag, but we don't seem to be using it
anywhere. Since acquire_sample_rows() returns palloced tuples, can't we let
Pavan Deolasee pavan.deola...@gmail.com writes:
I first thought that analyze and vacuum can not run concurrently on the same
table since they take a conflicting lock on the table. So even if we ignore
the analyze process while calculating the OldestXmin for vacuum, we should
be fine since we
On Jun 8, 2011, at 10:33 AM, Greg Stark wrote:
This is kind of like the other property it would be nice to know about
transactions: that they've locked all the tables they're going to lock.
That sounds like something I've wanted for a very long time: the ability for a
transaction to say
12 matches
Mail list logo
