Jignesh Shah wrote:
On Tue, Dec 7, 2010 at 1:55 AM, Tom Lane wrote:
I could have sworn we'd refactored that to something like
bool ThereAreAtLeastNActiveBackends(int n)
which could drop out of the loop as soon as it'd established what we
really need to know...I'd suggest that we just
On Tue, Dec 7, 2010 at 1:55 AM, Tom Lane wrote:
> Greg Smith writes:
>> And the expensive part of the overhead beyond the delay itself is
>> CountActiveBackends(), which iterates over the entire procArray
>> structure.
>
> I could have sworn we'd refactored that to something like
> bool Th
On Tue, Dec 7, 2010 at 10:59 AM, Jignesh Shah wrote:
> On Tue, Dec 7, 2010 at 1:10 AM, Robert Haas wrote:
>> On Sun, Nov 21, 2010 at 7:15 PM, Ivan Voras wrote:
>>> The "sbwait" part is from FreeBSD - IPC sockets, but so much blocking on
>>> semwait indicates large contention in PostgreSQL.
>>
>>
On Tue, Dec 7, 2010 at 1:10 AM, Robert Haas wrote:
> On Sun, Nov 21, 2010 at 7:15 PM, Ivan Voras wrote:
>> The "sbwait" part is from FreeBSD - IPC sockets, but so much blocking on
>> semwait indicates large contention in PostgreSQL.
>
> I can reproduce this. I suspect, but cannot yet prove, that
On 12/6/10 10:03 AM, Tom Lane wrote:
> John Papandriopoulos writes:
>> I am still wondering whether the inheritance_planner(...) can be avoided if
>> the rowtypes of children are the same as the parent?
>
> Possibly, but it's far from a trivial change. The difficulty is that
> you'd need to gen
thanks for the replies !,
but actually I did figure out how to kill it
but pb_cancel_backend didn't work. here's some notes:
this has been hung for 5 days:
ns | 32681 | nssql | in transaction | f | 2010-12-01
15
resulting in: "fastadder_fastadderstatus": scanned 3000 of 58551
On Mon, Dec 06, 2010 at 03:24:31PM -0500, Josh Kupershmidt wrote:
> On Mon, Dec 6, 2010 at 2:48 PM, Jon Nelson wrote:
> > On Mon, Dec 6, 2010 at 1:46 PM, bricklen wrote:
> >> Not sure if anyone replied about killing your query, but you can do it
> >> like so:
> >>
> >> select pg_cancel_backend(5
On Mon, Dec 6, 2010 at 2:48 PM, Jon Nelson wrote:
> On Mon, Dec 6, 2010 at 1:46 PM, bricklen wrote:
>> Not sure if anyone replied about killing your query, but you can do it like
>> so:
>>
>> select pg_cancel_backend(5902); -- assuming 5902 is the pid of the
>> query you want canceled.
>
> How
On Mon, Dec 6, 2010 at 1:46 PM, bricklen wrote:
> On Sat, Dec 4, 2010 at 11:45 AM, felix wrote:
>> Ok, I caught one : an update that is stuck in waiting.
>> the first one blocks the second one.
>> ns | 5902 | nssql | UPDATE "fastadder_fastadderstatus" SET "built"
>> = false WHERE "fasta
On Sat, Dec 4, 2010 at 11:45 AM, felix wrote:
> Ok, I caught one : an update that is stuck in waiting.
> the first one blocks the second one.
> ns | 5902 | nssql | UPDATE "fastadder_fastadderstatus" SET "built"
> = false WHERE "fastadder_fastadderstatus"."service_id" = 1
Not sure if any
On Mon, Dec 6, 2010 at 12:10 PM, Robert Haas wrote:
> On Sun, Nov 21, 2010 at 7:15 PM, Ivan Voras wrote:
>> The "sbwait" part is from FreeBSD - IPC sockets, but so much blocking on
>> semwait indicates large contention in PostgreSQL.
>
> I can reproduce this. I suspect, but cannot yet prove, tha
John Papandriopoulos writes:
> The memory issue has indeed disappeared---there was no noticeable memory
> increase in the three queries below, with 4096 children. Inheritance
> planning overhead is around 20x for UPDATE/DELETE compared to SELECT;
> thankfully they are required much less freque
Greg Smith writes:
> And the expensive part of the overhead beyond the delay itself is
> CountActiveBackends(), which iterates over the entire procArray
> structure.
I could have sworn we'd refactored that to something like
bool ThereAreAtLeastNActiveBackends(int n)
which could drop out
On Sun, Nov 21, 2010 at 7:15 PM, Ivan Voras wrote:
> The "sbwait" part is from FreeBSD - IPC sockets, but so much blocking on
> semwait indicates large contention in PostgreSQL.
I can reproduce this. I suspect, but cannot yet prove, that this is
contention over the lock manager partition locks o
hello.
i tested how are distributed values xmin,xmax on pages.
in my tables . typically there are no more than 80 records
on pages.
maybe its possible to compress xmin & xmax values to
1 byte/per record (+table of transactions per page)?
its reduce the space when more than 1 record is
from the sa
15 matches
Mail list logo
