""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
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
---
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
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
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
"Íõ±¦±ø" <[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 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
> >>
> >>
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 identic
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
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
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,
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
"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
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_
> > 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'
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
17 matches
Mail list logo