> We saw a case recently where a hash join was using much more memory than
> it was supposed to, causing failure when the server ran out of memory.
Yes. I had the same problem a few month ago,
http://archives.postgresql.org/pgsql-general/2004-09/msg00410.php
It turned out that the cost estimates
Hi,
I am trying to build postgresql-8.0.1 with icc-8.1.028 on a Linux
RHEL AS3 SMP Itanium2 machine and I get an error as follows when I run
configure --enable-thread-safety as follows-
---
Tom, Peter,
I have been able to compile and sucessfully run pgSQL after replacing
the asm statement in postgresql-8.0.1/src/include/storage/s_lock.h
with an equivalent intrinsic for the Itanium platform-
--BEGIN OLD
s_lock.h-
While going through the usual motions needed to fork a child process of
the postmaster, it occurred to me that there's a fair bit of duplicated
code involved. There are also #ifdef for various situations (BeOS,
LINUX_PROFILE, and EXEC_BACKEND), which makes the code yet more ugly. I
think we cou
Thanks
I try it.
| -邮件原件-
| 发件人: [EMAIL PROTECTED]
| [mailto:[EMAIL PROTECTED] 代表 Thomas F.O'Connell
| 发送时间: 2005年3月3日 20:38
| 收件人: Qu Tianlian
| 抄送: PostgreSQL-development; Slony Mailing List
| 主题: Novice Slony User (Was [HACKERS] hi all)
|
| First things first: try posting to the Slony
Thomas F.O'Connell wrote:
I have a feeling Bruce was referring to item 1.4:
http://developer.postgresql.org/readtext.php?src/FAQ/
FAQ_DEV.html+Developers-FAQ#1.4
It has never been standard practice to ask for comments before the
development of small features, such as this one. The recently duplic
Andrew,
> Incidentally, the fly in this particular pot of ointment is that we
> potentially log a lot more than just statements.
Oh, yeah, but just about anything can be put in the "statement" field; errors,
disconnects, etc.
Hmmm ... though we don't currently apply "log line prefix" to tho
Josh Berkus wrote:
Tom,
But log_line_prefix works fine for all destinations, which is exactly
why this new facility isn't a destination. You're just confusing
matters by wanting to treat it as one.
Hmmm ... hey, if we just allowed extra text in log_line_prefix, and allowed %$
to enclose
Tom,
> But log_line_prefix works fine for all destinations, which is exactly
> why this new facility isn't a destination. You're just confusing
> matters by wanting to treat it as one.
Hmmm ... hey, if we just allowed extra text in log_line_prefix, and allowed %$
to enclose the statement with l
We saw a case recently where a hash join was using much more memory than
it was supposed to, causing failure when the server ran out of memory.
The hash join code is supposed to spill tuples to disk when the
hashtable exceeds work_mem, but this failed to save us because the
algorithm is not adaptiv
> "Merlin Moncure" <[EMAIL PROTECTED]> writes:
> > Ok, problem was due to recursive pl/pgsql function and a recursion
loop
> > in the data. I traced this problem to the data: somebody disabled
the
> > recursion check constraint.
> > I've never had this actually happen before. It totally nuked the
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> Ok, problem was due to recursive pl/pgsql function and a recursion loop
> in the data. I traced this problem to the data: somebody disabled the
> recursion check constraint.
> I've never had this actually happen before. It totally nuked the
> serve
Josh Berkus writes:
>> I wonder whether this could be defined in a way that lets it replace
>> log_line_prefix ... otherwise we have to think about the interaction of
>> the two facilities.
> Well, that's why I like the idea of using log_destination. It makes it
> clear
> that log_line_prefix
I wrote:
> Ok, I have a fairly nasty situation. I am having a production server
> that is crashing upon execution of a pl/pgsql function...on code that
> has been working flawlessly for weeks. My production server is
running
> 8.0 on win32 and I was able to 'sort-of' reproduce the behavior on my
Tom,
> That seems a bit bizarre to me. The facility isn't a new log
> destination; what it is is a different way of formatting what's
> sent to the log.
It's not, but it functions like one. And ultimately, the destination *is*
someplace different; likely the DBA will be piping the log output t
Ok, I have a fairly nasty situation. I am having a production server
that is crashing upon execution of a pl/pgsql function...on code that
has been working flawlessly for weeks. My production server is running
8.0 on win32 and I was able to 'sort-of' reproduce the behavior on my
development machi
Josh Berkus writes:
>> What would we like the postgresql.conf option to be? I was thinking
>> log_statements_as_inserts = (t/f)
> Nope.
> log_destination = 'inserts' #not a new GUC!
That seems a bit bizarre to me. The facility isn't a new log
destination; what it is is a different way of
Josh,
> >>I am looking at having one of our guys write up the code to allow
> >>logging as insert statements. I have a couple of questions.
> >>
> >>What would we like the postgresql.conf option to be? I was thinking
> >>log_statements_as_inserts = (t/f)
Nope.
log_destination = 'inserts' #n
Josh Berkus writes:
> I should be able to run more OLTP benchmarks, and a DSS benchmark, within the
> next week. Please wait until I complete those before considering an 8.0.2
> release with the new code.
Sure, there's no hurry to push out 8.0.2 (and we need to have some beta
testing done on
Hi,
I have a 7.4.3 installation where a small plperl function seems to have
side-effects. In the example below I run an ordinary SELECT first, nothing
special with the table. Thereafter I call the plperl function and then I
rerun the SELECT query. This time it doesn't return the expected result. T
> Ühel kenal päeval (teisipäev, 1. märts 2005, 14:54-0500), kirjutas
> [EMAIL PROTECTED]:
>> Now, it occurs to me that if my document reference table can refer to
>> something other than an indexed primary key, I can save a lot of index
>> processing time in PostgreSQL if I can have a "safe" analog
> I'm wondering,
> is there any sense to cluster table using two-column index ?
>
>
We've had this discussion a few weeks ago. Look at the archives for my
post "One Big Trend "
The problem is that while the statistics can resonably deal with the
primary column it completely misses the trends p
Dave Cramer <[EMAIL PROTECTED]> writes:
> I was just looking at the config parameters, and you have the shared buffers
> set to 60k, and the effective cache set to 1k
I was actually going to suggest that the performance degradation might be
because of an excessively high shared_buffers setti
Hi there,
I'm trying to understand if I have something to optimize in my
query which is basically looks like a bunch of many intervals:
(ipix >= 341288409261670400 AND ipix < 341358778005848064)
OR (ipix >= 341710621726736384 AND ipix < 341728213912780800)
OR (ipix >= 341728213912780800 AND ipix
I'm wondering,
is there any sense to cluster table using two-column index ?
Regards,
Oleg
_
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Interne
Ühel kenal päeval (teisipäev, 1. märts 2005, 14:54-0500), kirjutas
[EMAIL PROTECTED]:
> Now, it occurs to me that if my document reference table can refer to
> something other than an indexed primary key, I can save a lot of index
> processing time in PostgreSQL if I can have a "safe" analogy to CT
First things first: try posting to the Slony mailing list:
[EMAIL PROTECTED]
-tfo
--
Thomas F. O'Connell
Co-Founder, Information Architect
Sitening, LLC
http://www.sitening.com/
110 30th Avenue North, Suite 6
Nashville, TN 37203-6320
615-260-0005
On Mar 2, 2005, at 7:23 PM, Qu Tianlian wrote:
Hi al
Tom Lane wrote:
> #if defined(__GNUC__) || defined(__ICC)
>
> Can anyone say a reason why the above #if is not wrong ... ie,
> are there any platforms where icc does handle gcc asm syntax,
> and if so exactly which ones are they?
I believe I added that a few releases ago. The platform is IA32.
28 matches
Mail list logo
