Kevin Brown wrote:
Let me expand a little on some of the peculiarities of
shared libraries on AIX:
- A normal AIX shared library is called libXX.a
It is an 'ar' archive that contains the shared object(s).
Ah, so the problem really boils down to funny naming conventions.
If they use .a
On Mon, 2006-09-11 at 11:29 -0400, Tom Lane wrote:
Mark Wong [EMAIL PROTECTED] writes:
Tom Lane wrote:
It would be nice to see some results from the OSDL tests with, say, 4,
8, and 16 lock partitions before we forget about the point though.
Anybody know whether OSDL is in a position to
On Mon, 2006-09-11 at 06:20 -0700, Say42 wrote:
I intend to play with some optimizer aspects. Just for fun.
Cool. If you think its fun (it is), you're half way there.
I'm a
novice in the DBMS development so I can not promise any available
results but if it can be useful even as yet another
On Mon, 2006-09-11 at 14:25 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Is this an 8.2 thing?
You are joking, no?
Confirming, using an open question, and a smile.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
---(end
Alvaro Herrera [EMAIL PROTECTED] writes:
Christopher Browne wrote:
It seems to me that there is some value in putting together a script
that tries to identify some of the interesting bits of the toolchain.
Yeah; but why not just a bunch of commands, some of which are expected
to work on
Hi,
What's the status of the bitmap index patch? Have you worked on it since
the last posted patch
(http://archives.postgresql.org/pgsql-patches/2006-08/msg3.php)?
I've started to review it, to get it into CVS early in the 8.3 cycle. I
just want to make sure that I'm working on the
Simon Riggs [EMAIL PROTECTED] writes:
That's what I want to do:
1. Replace not very useful indexCorrelation with indexClustering.
An opinion such as not very useful isn't considered sufficient
explanation or justification for a change around here.
There's been some previous discussion about
Alvaro Herrera [EMAIL PROTECTED] writes:
Gregory Stark wrote:
Well char doesn't have quite the same semantics as CHAR(1). If that's the
consensus though then I can work on either fixing char semantics to match
CHAR(1) or adding a separate type instead.
What semantics?
The main bit
Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
btw - the hashjoin is bad was more or less based on the observation
that nearly all of the cpu is burned in hash-related functions in the
profile (when profiling over a longer period of time those accumulate
even more % of the time
Simon Riggs wrote:
This type of work is 90% analysis, 10% coding. You'll need to do a lot
of investigation, lots of discussion and listening.
I absolutely agree with you and I am not about to rush into coding
right now. First of all I'm going to dig a lot in the PG sources,
readme's and so on.
Tom Lane wrote:
In our case, we have libpq.a and libpq.so in the same directory,
so unless you link with -brtl you will get a static link
(because libpq.a is a static library).
I wonder whether we ought to suppress building (or at least
installing)
our .a libraries at all on AIX. Adding
At risk of being chastised for reviving old issues, I was wondering,
what are the chances were of getting the dump / restore selectivity into
8.2 ? I am referring to the idea that, instead of the current 2 parts, a
dump could be broken up into 3 parts, namely tables, data and everything
else,
Simon Riggs [EMAIL PROTECTED] writes:
On Mon, 2006-09-11 at 11:29 -0400, Tom Lane wrote:
Great, thanks. The thing to twiddle is LOG2_NUM_LOCK_PARTITIONS in
src/include/storage/lwlock.h. You need a full backend recompile
after changing it, but you shouldn't need to initdb, if that helps.
Albe Laurenz [EMAIL PROTECTED] writes:
Tom Lane wrote:
I think there's a reasonable argument that by installing a .a file that
isn't a shared library, we are violating the platform's conventions.
The natural way in AIX would be:
- Create libpq.so
- Create libpq.a by 'rm -f libpq.a; ar -rc
It has bothered me for some time that we have currentItemData and
currentMarkData fields in IndexScanDescData, while it's really indexam's
private data. They should be in the indexam opaque structure.
At the moment, they're used in gist and hash access methods, and they're
not used in b-tree
Heikki Linnakangas [EMAIL PROTECTED] writes:
What's the status of the bitmap index patch? Have you worked on it since
the last posted patch
(http://archives.postgresql.org/pgsql-patches/2006-08/msg3.php)?
Gavin and Jie have made major changes since that version (or at least
they'd better
Am Dienstag, 12. September 2006 15:22 schrieb Naz Gassiep:
At risk of being chastised for reviving old issues, I was wondering,
what are the chances were of getting the dump / restore selectivity into
8.2 ?
Zero, because feature freeze is over.
Did this item make it onto the to-do list? If
Am Dienstag, 12. September 2006 12:48 schrieb Say42:
That is why caching should be taking into account
during joining cost calculation.
If you know of a more effective way to do that beyond the effective_cache_size
parameter that we have now, let us know.
--
Peter Eisentraut
Gregory Stark [EMAIL PROTECTED] writes:
It's possible there's some sort of block-wise correlated measure
which would be even better for our needs.
Actually, it seems obvious to me that the correlation measure ought to
ignore within-block ordering, but right now it does not. OTOH it's not
clear
Zero, because feature freeze is over.
Aah yes, fair enough
If you find this feature interesting, you are free to drive the development
yourself, independent of it appearing on any list. To avoid tears later on,
look for a consensus about the merit of the feature first, though
This has
Naz Gassiep [EMAIL PROTECTED] writes:
At risk of being chastised for reviving old issues, I was wondering,
what are the chances were of getting the dump / restore selectivity into
8.2 ?
None, but feel free to start coding for 8.3.
I am referring to the idea that, instead of the current 2
Heikki Linnakangas [EMAIL PROTECTED] writes:
It has bothered me for some time that we have currentItemData and
currentMarkData fields in IndexScanDescData, while it's really indexam's
private data. They should be in the indexam opaque structure.
Can't get very excited about it, but if you
That seems like a rather spectacular overstatement of the likely
benefits, not to mention a misdescription of what was discussed.
AFAIR what was discussed was separating
Yes, that is what was discussed.
- schema stuff needed before loading data
- table data
- schema
We can pass on what we've seen when running tests here with different
BufMapping and LockMgr partition sizes.
We use a TPC-C inspired benchmark. Currently it is configured to run 25
backend processes. The test runs for 16 minutes as this is the minimum
amount of time we can run and obtain useful
Tom Lane wrote:
The natural way in AIX would be:
- Create libpq.so
- Create libpq.a by 'rm -f libpq.a; ar -rc libpq.a libpq.so'
- Install only libpq.a
Hm. This seems possible with some moderate hacking on Makefile.shlib
(certainly it'd be no more invasive than the existing
Hi Heikki,
Gavin and I are trying to merge our changes together this week. We will post
a new patch by the end of this week. This patch will include some style
fixes, bug fixes, and the stream bitmap implementation.
I will look into the problems you have mentioned in this email. Yes, vacuum
Strong, David [EMAIL PROTECTED] writes:
When using 16 buffer and 16 lock partitions, we see that BufMapping
takes 809 seconds to acquire locks and 174 seconds to release locks. The
LockMgr takes 362 seconds to acquire locks and 26 seconds to release
locks.
When using 128 buffer and 128 lock
Tom,
Thanks for the feedback. We'll run a few tests with differing buffer and
lock partition sizes in the range you're interested in and we'll let you
know what we see.
Our workload is not fixed, however. Our benchmark does not follow the
strict TPC-C guideline of using think times etc. We throw
On Wed, 2006-09-06 at 12:01 -0400, Bruce Momjian wrote:
Simon Riggs wrote:
1. Notes on restartable recovery
Previously submitted
2. Notes on standby functionality
3. discussion on rolling your own record-level polling using
pg_xlogfile_name_offset()
Given below, but not in SGML yet.
Simon Riggs wrote:
In general, log shipping between servers running different release
levels will not be possible. However, it may be possible for servers
running different minor release levels e.g. 8.2.1 and 8.2.2 to
inter-operate successfully. No formal support for that is offered and
there
On Tue, 2006-09-12 at 13:25 -0400, Andrew Dunstan wrote:
Simon Riggs wrote:
In general, log shipping between servers running different release
levels will not be possible. However, it may be possible for servers
running different minor release levels e.g. 8.2.1 and 8.2.2 to
I again will not be able to complete the release notes today as
promised. My next target date is Monday, August 18. Sorry.
--
Bruce Momjian [EMAIL PROTECTED]
EnterpriseDBhttp://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Bruce Momjian wrote:
I again will not be able to complete the release notes today as
promised. My next target date is Monday, August 18. Sorry.
Will that be in a few years, or are you traveling backwards in time? ;-)
cheers
andrew
---(end of
Andrew Dunstan wrote:
Bruce Momjian wrote:
I again will not be able to complete the release notes today as
promised. My next target date is Monday, August 18. Sorry.
Will that be in a few years, or are you traveling backwards in time? ;-)
Sorry, September 18. I will probably be
On Tue, Sep 12, 2006 at 02:31:22PM -0400, Bruce Momjian wrote:
I again will not be able to complete the release notes today as
promised. My next target date is Monday, August 18. Sorry.
The next Monday, August 18, is in 2008. Surely that'll be
enough time ;-)
--
Michael Fuhr
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Michael Fuhr
Sent: 12 September 2006 19:57
To: Bruce Momjian
Cc: PostgreSQL-development
Subject: Re: [HACKERS] Release notes
On Tue, Sep 12, 2006 at 02:31:22PM -0400, Bruce Momjian wrote:
I
Dave Page wrote:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Michael Fuhr
Sent: 12 September 2006 19:57
To: Bruce Momjian
Cc: PostgreSQL-development
Subject: Re: [HACKERS] Release notes
On Tue, Sep 12, 2006 at 02:31:22PM -0400,
Simon Riggs [EMAIL PROTECTED] writes:
My memory is lousy at the best of times, but when have we had a minor
release that would have broken this due to changed format? OTOH, the
Primary and Backup servers need the same config settings (e.g.
--enable-integer-datetimes), architecture,
Gregory Stark [EMAIL PROTECTED] writes:
Simon Riggs [EMAIL PROTECTED] writes:
My memory is lousy at the best of times, but when have we had a minor
release that would have broken this due to changed format?
Not often, which is why I mention the possibility of having
interoperating minor
Bruce Momjian wrote:
Dave Page wrote:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Michael Fuhr
Sent: 12 September 2006 19:57
To: Bruce Momjian
Cc: PostgreSQL-development
Subject: Re: [HACKERS] Release notes
On Tue, Sep 12, 2006 at 02:31:22PM
Folks,
During past days I have been coding the UUID datatype which has been fun
and great learning curve for me. Here is the current progress:
- basic i/o functions are done.
- various records for pg_class,pg_operator,pg_amop etc, are added
- the additions pass the regression check :)
- btree
Tom Lane [EMAIL PROTECTED] writes:
This would be the exception, not the rule, and should not be documented
as if it were the rule. It's not really different from telling people
to expect a forced initdb at a minor release: you are simply
misrepresenting the project's policy.
Well it's never
Gregory Stark [EMAIL PROTECTED] writes:
Well it's never been a factor before so I'm not sure there is a
policy. Is there now a policy that WAL files like database formats are
as far as possible not going to be changed in minor versions?
This means if there's a bug fix that affects WAL records
None, but feel free to start coding for 8.3.My coding skills are still nascent,
but I shall do my best.
My coding skills are still pretty nascent, but I shall do my best.
That seems like a rather spectacular overstatement of the likely
benefits, not to mention a misdescription of what was
Naz Gassiep wrote:
None, but feel free to start coding for 8.3.My coding skills are still
nascent, but I shall do my best.
My coding skills are still pretty nascent, but I shall do my best.
That seems like a rather spectacular overstatement of the likely
benefits, not to mention a
Alvaro Herrera [EMAIL PROTECTED] writes:
Naz Gassiep wrote:
Did this make it into the to-do list for 8.3 ?
Don't worry about the to-do list too much.
In particular, if you're imagining that being in the TODO list will
in itself cause anyone to work on it, you're much mistaken about this
If everything goes okay, I should be able to submit a beta patch for
reviewing during next two weeks (and get shot at :))
/me starts loading...
Regards,
Gevik
---(end of broadcast)---
TIP 1: if posting/reading through Usenet,
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
Tom Lane wrote:
Could we see the actual EXPLAIN ANALYZE results for the slow plan?
http://www.kaltenbrunner.cc/files/dbt3_explain_analyze.txt
Well, indeed it seems that the hash join is just an innocent bystander:
the bulk of the runtime (all but
I have just realized that the recent patches in pgbench have altered its
behavior in a way that destroys reproducibility of results --- I'm
seeing reported TPS numbers about twice what they were before that.
I'd love to say we did something in the past month that made the backend
2X faster,
Bruce Momjian wrote:
Dave Page wrote:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Michael Fuhr
Sent: 12 September 2006 19:57
To: Bruce Momjian
Cc: PostgreSQL-development
Subject: Re: [HACKERS] Release notes
On Tue, Sep 12, 2006 at
Peter Eisentraut wrote:
If you know of a more effective way to do that beyond the effective_cache_size
parameter that we have now, let us know.
I don't know the better way and it is not my goal at all. I think about
more accurate cost estimation of nested loops join and subqueries.
Usual case
Say42 [EMAIL PROTECTED] writes:
Usual case in data request is a joining detail and some master tables
into a single relation.
Optimizing on the basis of only one example is seldom a good idea...
and I think you are falling into that trap by supposing that there
is a usual case.
Say42 wrote:
select count(*) from conn.conn20060803 c
where
exists (select code from belg_mobile tc
...
Correction: replace 'trunk_codes' with 'belg_mobile'.
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an
On Fri, Sep 01, 2006 at 03:28:36PM -0400, Stephen Frost wrote:
Overall, I really think 8.2 is going to be an excellent release. I wish
autovacuum could have been enabled by default and I'd just like to ask,
now and I'll try to remember again once 8.2 is out, please let's turn it
on by default
Tom Lane wrote:
Optimizing on the basis of only one example is seldom a good idea...
and I think you are falling into that trap by supposing that there
is a usual case.
Perhaps I am wrong but I assume normalization is a usual case, small
master (parent) tables are not very rare also.
Yes, my
55 matches
Mail list logo
