Tom Lane <[EMAIL PROTECTED]> wrote:
> > Why do index access methods use LP_DELETE?
>
> My recollection is that I deliberately used LP_DELETE for the
> known-dead-tuple marker so that there couldn't be any confusion with
> the use of LP_USED. AFAIR, LP_USED isn't actually used in indexes,
> so we
> On Fri, Aug 12, 2005 at 12:27:25PM +0900, Tatsuo Ishii wrote:
>
> > However even one of transactions, for example 647 commits, still it
> > shows as if 647 is a member of muitixid 3.
> >
> > test=# select * from pgrowlocks('t1');
> > locked_row | lock_type | locker | multi | xids
> > ---
On Fri, Aug 12, 2005 at 12:27:25PM +0900, Tatsuo Ishii wrote:
> However even one of transactions, for example 647 commits, still it
> shows as if 647 is a member of muitixid 3.
>
> test=# select * from pgrowlocks('t1');
> locked_row | lock_type | locker | multi | xids
> +--
Bruce Momjian writes:
> Do we automatically close files opened with AllocateFile() on
> ereport(ERROR)?
Yes ... that's more or less the point of having it ...
regards, tom lane
---(end of broadcast)---
TIP 9: In versions be
> Hi,
>
> With a help from Bruce, I wrote a small function which returns row
> locking information(see attached file if you are interested). Here is
> a sample result:
>
> test=# select * from pgrowlocks('t1');
> locked_row | lock_type | locker | multi
> +---++--
Bruce Momjian wrote:
> Do we automatically close files opened with AllocateFile() on
> ereport(ERROR)?
I found they are closed, fd.c comment says:
* fd.c will automatically close all files opened with AllocateFile at
* transaction commit or abort; this prevents FD leakage if a routine
* that c
Do we automatically close files opened with AllocateFile() on
ereport(ERROR)?
--
Bruce Momjian| http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> Why do index access methods use LP_DELETE?
My recollection is that I deliberately used LP_DELETE for the
known-dead-tuple marker so that there couldn't be any confusion with
the use of LP_USED. AFAIR, LP_USED isn't actually used in indexes,
so we cou
Tom Lane wrote:
> Bruce Momjian writes:
> >> O_DIRECT is only being used for WAL page writes (or I sure hope so
> >> anyway), so shared_buffers should be irrelevant.
>
> > Uh, O_DIRECT really just enables when open_sync is used, and I assume
> > that is not used for writing dirty buffers during a
Bruce Momjian writes:
>> O_DIRECT is only being used for WAL page writes (or I sure hope so
>> anyway), so shared_buffers should be irrelevant.
> Uh, O_DIRECT really just enables when open_sync is used, and I assume
> that is not used for writing dirty buffers during a checkpoint.
I double-check
Andrew - Supernews wrote:
> On 2005-08-12, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> > In light of this, may I ask whether it makes sense to compare the
> > performance of two runs with similar shared_buffer settings? With
> > O_DIRECT, I understand from this manpage that the OS is going to do
>
Hi Hackers,
I found index access methods use LP_DELETE for invisible tuples,
but it seems to be ok to remove LP_USED instead of adding LP_DELETE.
I tried the following simple replacements:
- '|= LP_DELETE' => '&= ~LP_USED'
- 'ItemIdDeleted' => '!ItemIdIsUsed'
and then, it passed all regressio
On 2005-08-12, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> In light of this, may I ask whether it makes sense to compare the
> performance of two runs with similar shared_buffer settings? With
> O_DIRECT, I understand from this manpage that the OS is going to do
> little or no page caching, so sha
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > In light of this, may I ask whether it makes sense to compare the
> > performance of two runs with similar shared_buffer settings? With
> > O_DIRECT, I understand from this manpage that the OS is going to do
> > little or no page cac
Tom Lane wrote:
> Most of the CVS activity in that time period had to with stuff like
> roles and the interval datatype. It's conceivable that these things
> had some marginal performance cost, but if so I'd have expected it to
> show up as extra CPU effort (more time checking permissions, say).
>
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> In light of this, may I ask whether it makes sense to compare the
> performance of two runs with similar shared_buffer settings? With
> O_DIRECT, I understand from this manpage that the OS is going to do
> little or no page caching, so shared_buffers sh
On Thu, Aug 11, 2005 at 09:02:03PM -0400, Tom Lane wrote:
> I am sure I will get some pushback if I propose reverting the O_DIRECT
> patch, so could you try to get some more-specific evidence? Like pull
> the CVS tree from just before and just after this patch and compare
> performance?
Quoth th
Mary Edie Meredith <[EMAIL PROTECTED]> writes:
> I have an example of runs that illustrate a performance
> problem that occurred between installing the 7/18 and 8/1
> development release codes.
I dug through the CVS logs to see what had changed, and I'm afraid there
is just one plausible-looking
I have an example of runs that illustrate a performance
problem that occurred between installing the 7/18 and 8/1
development release codes. I'm running on a PPC64 8-way system,
with 16GB of memory (on a 15GB virtual machine), with a DBT2
workload configured as a 16 warehouse DBT2 with 16 db
On Wed, Aug 10, 2005 at 02:11:48AM -0500, Thomas F. O'Connell wrote:
> I was recently witness to a benchmark of 7.4.5 on Solaris 9 wherein
> it was apparently demonstrated that fsync was the fastest option
> among the 7.4.x wal_sync_method options.
>
> If there's a way to make this information
On Sun, Aug 07, 2005 at 03:45:10PM -0400, Tom Lane wrote:
>
> I'm a bit hesitant to back-patch such a nontrivial and hard-to-test
> change, but it sure looks badly broken to me. Any thoughts about the
> risks involved?
If there were some way to test it reliably, it'd make me feel a lot
better.
I'm stuck with a web app that periodically has truly awful query
response times. The cause may be an interaction between system load,
vacuum-analyze scheduling, the occasional wild variation in join
selectivity, and stats collection. Logging the queries and running them
later doesn't create an obvi
[Please CC replies, thanks]
On Thu, Aug 11, 2005 at 02:17:30PM -0400, Tom Lane wrote:
> Martijn van Oosterhout writes:
> > What I'm trying to do now is use fcinfo->flinfo->fn_oid to lookup
> > pg_proc and get the return type from there, but something tells me
> > there must be an easier way.
>
>
Martijn van Oosterhout writes:
> I was thinking of actually also storing the oid in the typelem field
> but the docs imply this does something fancy with subscripting.
Yeah, like enable it ;-). You can't do that unless you are some kind
of array type. typelem pointing at yourself would be parti
Martijn van Oosterhout writes:
> What I'm trying to do now is use fcinfo->flinfo->fn_oid to lookup
> pg_proc and get the return type from there, but something tells me
> there must be an easier way.
No, I think you're stuck. The internal calls for type I/O routines
don't set up fn_expr (since th
Folks,
--
SQL statement with
input values
:java.lang.Integer:30239.
Please examine the SQLException for more information.
NestedException: java.sql.SQLException: ERROR: SELECT FOR UPDATE cannot
be applied to the nullable side of an outer join
-
[Please CC any replies so I don't have to follow them via the archives]
Hi,
I'm trying to create a set of types that are going to share the INPUT
and OUTPUT functions (written in C). For output you can determine the
type from the arguments, but for INPUT you can't. The prototype is
restricted (by
Kim Bisgaard <[EMAIL PROTECTED]> writes:
> I have noticed a deficiency in the current query optimizer related to
> "full outer joins". Tom Lane has confirmed to me that it will not be 8.1
> material.
The particular case you are complaining of is fixed in CVS tip. There
are related issues involv
On Wed, 2005-08-10 at 16:41 -0400, Tom Lane wrote:
> Matt Miller <[EMAIL PROTECTED]> writes:
> > It seems to me that contrib/dblink could greatly simplify the design and
> > coding of multi-user regression tests.
>
> I doubt it would be very useful, since
> a script based on that still doesn't let
I have a case that I though was an example of this issue,
and that this patch would correct. I applied this patch
to an 8.0.3 source distribution, but it didn't seem to
solve my problem.
In a nutshell, I have a LIMIT query where the planner
seems to favor a merge join over a nested loop. I've
si
Hi,
Red ears, looking down on my shoes!
Well I code one getsize my self using inv_seek.
Had disabled a lot of compiler warnings because I am reusing a lot of
spaghetti code for testing etc. This was proberly a hint for starting
to clean up the code.
Regards,
Søren
> On Tue, Aug 09, 2005 at 10
I have noticed a deficiency in the current query optimizer related to
"full outer joins". Tom Lane has confirmed to me that it will not be 8.1
material. I am not able to wait for 8.2
I am in the lucky situation that my project has money to hire
consultants, so I would be very interested in hea
32 matches
Mail list logo
