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.
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
Ü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 CTID.
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)
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
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 setting.
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
Ü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
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.
Josh Berkus josh@agliodbs.com 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
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' #not a new GUC!
Josh Berkus josh@agliodbs.com 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
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
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 to
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
Josh Berkus josh@agliodbs.com 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
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
server.
I
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
server.
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
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
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
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 those,
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
Thanks
I try it.
| --
| : [EMAIL PROTECTED]
| [mailto:[EMAIL PROTECTED] Thomas F.O'Connell
| : 200533 20:38
| : Qu Tianlian
| : PostgreSQL-development; Slony Mailing List
| : Novice Slony User (Was [HACKERS] hi all)
|
| First things first: try posting to the Slony mailing list:
|
|
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
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
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-
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
28 matches
Mail list logo
