On Sat, 11 Mar 2006, Oleg Bartunov wrote:
It's still not easy to come from Russia to Canada. I have to convince
officer in canadian embassy that
1) I have enough money for living in Canada
2) I don't want to immigrate
3) I'm a loyal citizen
Invitation from conference commitee could help me to
If so,
we could perhaps recode that part using a Mutex instead of
a critical
section - since it's not a performance critical path, the
difference
shouldn't be large. If I code up a patch for that, can you re-apply
SP1 and test it? Or is this a production system you can't
really
While trying to help somebody on IRC with slow queries against
information_schema i stumbled across the following EXPLAIN buglet (much
reduced from the original one and does not make a lot of sense therefore):
foo=# explain SELECT * FROM information_schema.constraint_column_usage
JOIN
Bernd Helmle [EMAIL PROTECTED]
Hi folks,
The supported syntax is
CREATE VIEW foo AS SELECT ... [WITH [LOCAL | CASCADED] CHECK OPTION];
The LOCAL and CASCADED keywords are optional when a CHECK OPTION is
specified, the default is CASCADED (this syntax creates a shift/reduce
conflict in the
I was talking with Jonathan Gennick about the INS/UPD/DEL RETURNING stuff, and he recommended looking into the way DB2 handles similar functionality. After looking into it a bit, it's more inline with what Tom's suggestion was regarding a query from the operation rather than returning the values
On Sunday 12 March 2006 09:40, Magnus Hagander wrote:
If so,
we could perhaps recode that part using a Mutex instead of
a critical
section - since it's not a performance critical path, the
difference
shouldn't be large. If I code up a patch for that, can you re-apply
SP1
Oleg,
Invitation from conference commitee could help me to get an official
letter
from my institute to embassy (1,2). But we still have 3)
I should get references for all members of my family from our police
department that we're not criminals :) There is no united database,
so I should get
Tatsuo Ishii wrote:
BTW, I noticed difference of outputs from pg_freespacemap and
pgstattuple.
I ran pgbench and inspected accounts table by using these tools.
pg_freespacemap:
sum of bytes: 250712
pgstattuple:
free_space: 354880
Shouldn't they be identical?
I would have
Tatsuo Ishii wrote:
BTW, I noticed difference of outputs from pg_freespacemap and
pgstattuple.
I ran pgbench and inspected accounts table by using these tools.
pg_freespacemap:
sum of bytes: 250712
pgstattuple:
free_space: 354880
Shouldn't they be identical?
No, because (a)
Tom Lane wrote:
Tatsuo Ishii wrote:
BTW, I noticed difference of outputs from pg_freespacemap and
pgstattuple.
I ran pgbench and inspected accounts table by using these tools.
pg_freespacemap:
sum of bytes: 250712
pgstattuple:
free_space: 354880
Shouldn't they be identical?
vacuum/fsm
Tatsuo Ishii wrote:
BTW, I noticed difference of outputs from pg_freespacemap and
pgstattuple.
I ran pgbench and inspected accounts table by using these tools.
pg_freespacemap:
sum of bytes: 250712
pgstattuple:
free_space: 354880
Shouldn't they be identical?
No,
Íõ±¦±ø [EMAIL PROTECTED] wrote
--Data Buffer Flush:Only flush the dirty database data(items) into the
disk
not including the log buffer.
In most cases, if you just flush the dirty database pages into disk without
related xlog records, you are violating WAL. A possible consequence is data
Tatsuo Ishii [EMAIL PROTECTED] writes:
That sounds strange to me. Each record of accounts tables is actually
exactly same, i.e fixed size. So it should be possible that UPDATE
reuses any free spaces made by previous UPDATE. If FSM neglects those
free spaces because they are uselessly small,
The point here is that if tuples require 50 bytes, and there are 20
bytes free on a page, pgstattuple counts 20 free bytes while FSM
ignores the page. Recording that space in the FSM will not improve
matters, it'll just risk pushing out FSM records for pages that do
have useful amounts of free
Christopher Kings-Lynne wrote:
The point here is that if tuples require 50 bytes, and there are 20
bytes free on a page, pgstattuple counts 20 free bytes while FSM
ignores the page. Recording that space in the FSM will not improve
matters, it'll just risk pushing out FSM records for pages that
On Fri, 2006-03-10 at 11:21 +0100, Bernd Helmle wrote:
Please find attached a patch that implements SQL92-compatible updatable
views.
I'm currently reviewing this. Comments later...
Please note that the patch isn't complete yet
Do you have a list of known TODO items?
-Neil
Magnus Hagander [EMAIL PROTECTED] wrote
Ok, I've coded up a patch that changes the code to use a mutex instead.
Are we asserting the problem is caused by the spinlock random wake-up order?
I am not sure why this would fix the problem. If my memory serves, a
critical section might be a problem
17 matches
Mail list logo
