am Mon, dem 19.05.2008, um 23:56:27 -0600 mailte kevin kempter folgendes:
> Hi all;
>
> I have a query that does this:
>
> update tab_x set (inactive_dt, last_update_dt) =
> ((select run_dt from current_run_date), (select run_dt from
> current_run_date))
> where
> cust_id::text || loc_id::text
Hi all;
I have a query that does this:
update tab_x set (inactive_dt, last_update_dt) =
((select run_dt from current_run_date), (select run_dt from
current_run_date))
where
cust_id::text || loc_id::text in
(select cust_id::text || loc_id::text from summary_tab);
The current_run_date table h
The real question in my mind is why this turns into a bottleneck before
the similar task of cleaning the 16MB XLOG segment does. I expected
that one would need to be cracked before the CLOG switch time could
possibly be an issue, but reports from the field seem to suggest
otherwise.
H
Greg Smith <[EMAIL PROTECTED]> writes:
> The real question in my mind is why this turns into a bottleneck before
> the similar task of cleaning the 16MB XLOG segment does.
Because we do the latter off-line, or at least try to.
regards, tom lane
--
Sent via pgsql-perform
On Mon, 19 May 2008, Matthew Wakeling wrote:
Does it really take that long to zero out 8kB of RAM? I thought CPUs were
really quick at doing that!
You don't get the whole CPU--you get time slices of one. Some of the
cases complaints have come in about have over a thousand connections all
fi
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Matthew Wakeling wrote:
>> Does it really take that long to zero out 8kB of RAM? I thought CPUs were
>> really quick at doing that!
> Yea, that was my assumption too.
You have to write the page (to be sure there is space for it on disk)
not only zero i
Matthew Wakeling wrote:
> On Fri, 16 May 2008, Tom Lane wrote:
> > One additional point: this means that one transaction in every 32K
> > writing transactions *does* have to do extra work when it assigns itself
> > an XID, namely create and zero out the next page of pg_clog. And that
> > doesn't j
Alvaro Herrera <[EMAIL PROTECTED]> writes:
pg_clog is allocated in pages of 8kB apiece(*). On allocation, pages are
zeroed, which is the bit pattern for "transaction in progress". So when
a transaction starts, it only needs to ensure that the pg_clog page that
corresponds to it is allocated, bu
