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'
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 information_
"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
> conf
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 i
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,
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 shoul
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 t
> 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 identic
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
> >>
> >>
"Íõ±¦±ø" <[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 d
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 sma
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 sp
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 d
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 pro
17 matches
Mail list logo
