On Sat, Sep 02, 2006 at 09:26:36PM -0700, Joshua D. Drake wrote:
I just spent 1/2 hour fixing the multi-value UPDATE
patch for the code drift caused by UPDATE/RETURNING. The patch is a
simple grammar macro. Any coder could have taken that, reviewed it, and
applied it, but no one did.
Tom Lane [EMAIL PROTECTED] writes:
The project policy has always been that we don't change on-disk formats
in minor releases. I'm not entirely clear why you are so keen on
carving out an exception for WAL data.
I had always thought of the policy as initdb is not required not no on-disk
Tom Lane wrote:
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
Jim C. Nasby wrote:
There's been talk in the past of having some kind of system that
automatically attempts to build things that are in the patch queue, both
as an initial sanity-check and as a means to detect when something
bit-rots... perhaps it's becoming worthwhile to set that up.
After
Say42 wrote:
Perhaps I am wrong but I assume normalization is a usual case, small
master (parent) tables are not very rare also.
Yes, my example is unusual but it is _real_ and demonstrate PG
optimizer inaccuracy. Why don't we make PG optimizer more close to
reality if we can? Is it so
On Tue, 2006-09-12 at 16:23 -0400, Tom Lane wrote:
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
On Tue, 2006-09-12 at 12:40 -0400, Tom Lane wrote:
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
Hi, Tom,
Tom Lane wrote:
AFAIR what was discussed was separating
- schema stuff needed before loading data
- table data
- schema stuff needed after loading data
where the last category boils down to indexes and then foreign keys.
All the other stuff such as functions
Patch adds GIN documentation and slightly improves GiST docs.
Somebody of native English speakers, pls, check the text... Thank you.
gindocs.gz
Description: application/gzip
---(end of broadcast)---
TIP 4: Have you searched our list archives?
Peter Eisentraut wrote:
But you haven't offered any analysis about the cause of this problem, so any
speculation about normalization, usual cases, caching effects and so on are
unfounded and premature.
Ok. My previous message was a bit pompous and unfounded. Sorry.
Below I'll try to explain
Tom Dunstan wrote:
The idea was that patch authors could either run it manually or stick it
in a cron so they could get emailed when the patch no longer cleanly
applied, or when the patched source failed in make, make check etc.
Obviously my motivation was to keep the enum patch up to date
Tom,
I'm currently resyncing my parser with the changes you made to
prepared statement logging. Everything is OK apart from an
inconsistency between log_duration and log_min_duration_statement.
* With log_duration, we have:
protocol : LOG: statement: execute my_query: SELECT * FROM shop WHERE
Alvaro Herrera wrote:
I submitted a patch to Andrew, but it needed a couple of tweaks
(disabling patching on vpath builds, for example) and I don't think I
ever got around to resubmitting it, but if there's more general interest
I'll do so.
Huh, why would you disable patching on vpath
Tom Dunstan wrote:
Alvaro Herrera wrote:
I submitted a patch to Andrew, but it needed a couple of tweaks
(disabling patching on vpath builds, for example) and I don't think I
ever got around to resubmitting it, but if there's more general interest
I'll do so.
Huh, why would you disable
Alvaro Herrera wrote:
Huh, but the patch can be applied with -R to revert it after the
buildfarm run ... the one problem I can see is if the patch fails for
some reason; for which I'd suggest running a patch --dry-run as a first
step, checking that it applies cleanly, and only continue in
Guillaume Smet [EMAIL PROTECTED] writes:
I attached a patch to improve the consistency. It adds statement: for
every case.
Isn't that just bloating the log? And weren't you the one complaining
about log volumes to begin with?
The reason it is why it is is that Bruce wanted the wording to
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
Tom Lane wrote:
Apparently we've made the planner a bit too optimistic about the savings
that can be expected from repeated indexscans occurring on the inside of
a join.
effective_cache_size was set to 10GB(my fault for copying over the conf
Andrew Dunstan wrote:
Tom's idea of making a temp copy of the repo and patching that would work,
but if you're going to do that why do a vpath build anyway?
In this case, the answer is to make sure that your patch works when
*someone else* does a vpath build.
Regarding the idea of a list
Say42 [EMAIL PROTECTED] writes:
... Let's take my pervious example (I repost query and some lines
from 'explain' here for convenience):
select count(*) from conn.conn20060803 c where
exists (select code from belg_mobile tc
where c.bnum = tc.code and c.bnum like tc.code || '%'
Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
Tom Lane wrote:
Apparently we've made the planner a bit too optimistic about the savings
that can be expected from repeated indexscans occurring on the inside of
a join.
effective_cache_size was set to 10GB(my fault for copying
On 9/13/06, Tom Lane [EMAIL PROTECTED] wrote:
Guillaume Smet [EMAIL PROTECTED] writes:
I attached a patch to improve the consistency. It adds statement: for
every case.
Isn't that just bloating the log? And weren't you the one complaining
about log volumes to begin with?
As I told you, I
Tom Lane wrote:
Is it
possible that the rules have changed across AIX versions,
and that the code in there now is needful for older versions?
I don't think that this behaviour has changed. I remember it from
AIX 4.3.2.
AIX 4.3 is the first version to support the -brtl. The current
On Wed, Sep 13, 2006 at 10:47:09AM -0400, Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
Tom Lane wrote:
Apparently we've made the planner a bit too optimistic about the savings
that can be expected from repeated indexscans occurring on the inside of
a join.
The patch did not work for me :-(
My buildfarm members failed in local testing to execute the
install-check, because initdb failed to find libpq.so.
Make check did succeed, so I think there is a possibility of getting it
working, but it won't be as simple as adding -brtl to the template.
I was
The patch did not work for me :-(
My buildfarm members failed in local testing to execute the
install-check, because initdb failed to find libpq.so.
Make check did succeed, so I think there is a possibility of
getting it
working, but it won't be as simple as adding -brtl to the
Guillaume Smet [EMAIL PROTECTED] writes:
IMHO, it's more logical to remove it as the text after statement: is
not a statement in the extended query protocol case.
Well, I was never particularly enamored of the idea that we should put
statement: into everything generated by log_statement. My
On 9/13/06, Tom Lane [EMAIL PROTECTED] wrote:
statement: querystring Simple Query
parse stmt: querystring Parse
bind stmt/portal: querystring Bind
execute stmt/portal: querystringExecute
I agree with that.
Hmmm, AFAICS,
Joshua D. Drake [EMAIL PROTECTED] writes:
I have seen some patches come across with this. Is this done, or do I
still need to work on it?
Teodor added an uninstall for hstore, and I think Michael has fixed all
the problems in the existing scripts, but we still lack uninstall
scripts for the
FYI, in going through the release notes, I would like to remind
committers that it is important to mention if the commit was backpatched
to any earlier release. Not only is this valuable for making the
release notes, but it also helps people looking at the commit message.
--
Bruce Momjian
Simon Riggs wrote:
On Mon, 2006-09-11 at 06:20 -0700, Say42 wrote:
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.
Not
Bruce Momjian wrote:
FYI, in going through the release notes, I would like to remind
committers that it is important to mention if the commit was
backpatched to any earlier release.
Backpatches usually happen after the commit to the head branch has been
made, so the information is not
Peter Eisentraut wrote:
Bruce Momjian wrote:
FYI, in going through the release notes, I would like to remind
committers that it is important to mention if the commit was
backpatched to any earlier release.
Backpatches usually happen after the commit to the head branch has been
made, so
On Wed, 2006-09-13 at 14:24 +0400, Teodor Sigaev wrote:
Patch adds GIN documentation and slightly improves GiST docs.
Somebody of native English speakers, pls, check the text... Thank you.
I have some minor changes that reworded some parts that were confusing
to me.
I don't fully understand
The following is a proposal for work I'd like to do to force
long-running backend processes to reprepare their prepared statements.
It would be used in cases where the user knows they have made a database
change that will invalidate an existing prepared statement.
I look forward to comments
Simon,
In the 16/16 (16 buffer partitions/16 lock partitions) test, the
WALInsertLock lock had 14643080 acquisition attempts and 12057678
successful acquisitions on the lock. That's 2585402 retries on the lock.
That is to say that PGSemaphoreLock was invoked 2585402 times.
In the 128/128 test,
Bruce Momjian [EMAIL PROTECTED] writes:
FYI, in going through the release notes, I would like to remind
committers that it is important to mention if the commit was backpatched
to any earlier release. Not only is this valuable for making the
release notes, but it also helps people looking at
[EMAIL PROTECTED] (Rocco Altier) writes:
Tom Lane wrote:
Is it
possible that the rules have changed across AIX versions,
and that the code in there now is needful for older versions?
I don't think that this behaviour has changed. I remember it from
AIX 4.3.2.
AIX 4.3 is the first
Stephen Marshall [EMAIL PROTECTED] writes:
The following is a proposal for work I'd like to do to force
long-running backend processes to reprepare their prepared statements.
It would be used in cases where the user knows they have made a database
change that will invalidate an existing
Jim C. Nasby wrote:
There's been talk in the past of having some kind of system that
automatically attempts to build things that are in the patch queue, both
as an initial sanity-check and as a means to detect when something
bit-rots... perhaps it's becoming worthwhile to set that up.
After
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
FYI, in going through the release notes, I would like to remind
committers that it is important to mention if the commit was backpatched
to any earlier release. Not only is this valuable for making the
release notes, but it also
Tom,
Thanks for the update on the roadmap. I have a couple of questions:
1. Is the invalidation of stored plans going to be part of 8.2? If not,
any idea when it would be available? I'd be willing to work on this, if
it would help.
2. Is there any plan for the other part of my proposal, i.e.
Bruce Momjian [EMAIL PROTECTED] writes:
I pull activity only from HEAD, so I do not see that tag. In fact, I
use our src/tools/pgcvslog rather than cvslog.
Not sure why we are maintaining our own script when there are much
better things out there:
http://freshmeat.net/projects/cvs2cl.pl/
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I pull activity only from HEAD, so I do not see that tag. In fact, I
use our src/tools/pgcvslog rather than cvslog.
Not sure why we are maintaining our own script when there are much
better things out there:
Marshall, Steve [EMAIL PROTECTED] writes:
1. Is the invalidation of stored plans going to be part of 8.2? If not,
any idea when it would be available? I'd be willing to work on this, if
it would help.
No, it did not get done; feel free to work on it for 8.3.
2. Is there any plan for the
Ron Mayer [EMAIL PROTECTED] writes:
It's common here for queries to vastly overestimate the
number of pages that would need to be read because
postgresql's guess at the correlation being practically 0
despite the fact that the distinct values for any given
column are closely packed on a few
Tom,
We have some results for you. We left the buffer partition locks at 128
as this did not seem to be a concern and we're still using 25 backend
processes. We ran tests for 4, 8 and 16 lock partitions.
For 4 lock partitions, it took 620 seconds to acquire locks and 32
seconds to release
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I pull activity only from HEAD, so I do not see that tag. In fact, I
use our src/tools/pgcvslog rather than cvslog.
Not sure why we are maintaining our own script when there are much
better things out there:
On Sep 13, 2006, at 14:44 , Gregory Stark wrote:
I think we need a serious statistics jock to pipe up with some
standard
metrics that do what we need. Otherwise we'll never have a solid
footing for
the predictions we make and will never know how much we can trust
them.
That said I'm
Marshall, Steve [EMAIL PROTECTED] writes:
1. Is the invalidation of stored plans going to be part of 8.2? If
not, any idea when it would be available? I'd be willing to work on
this, if it would help.
No, it did not get done; feel free to work on it for 8.3.
[steve's reply]:
Could you
On Sep 11, 2006, at 1:57 PM, Gregory Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
I think its's more important to pick bitpatterns that reduce the
number of
cases heap_deform_tuple has to think about while decoding the
length of a
field --- every if in that inner loop is expensive.
On Sep 13, 2006, at 6:56 PM, Tom Dunstan wrote:
Regarding the idea of a list of approved patch authorisers, don't
we have
such a group now? i.e. committers.
Right, and if committers or others are willing to put in the time
required to verify that patches aren't nasty before going onto the
Andrew Dunstan wrote:
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I pull activity only from HEAD, so I do not see that tag. In fact, I
use our src/tools/pgcvslog rather than cvslog.
Not sure why we are maintaining our own script when there are much
Strong, David [EMAIL PROTECTED] writes:
We have some results for you. We left the buffer partition locks at 128
as this did not seem to be a concern and we're still using 25 backend
processes. We ran tests for 4, 8 and 16 lock partitions.
For 4 lock partitions, it took 620 seconds to acquire
On Sep 13, 2006, at 2:46 PM, Strong, David wrote:
We have some results for you. We left the buffer partition locks at
128
as this did not seem to be a concern and we're still using 25 backend
processes. We ran tests for 4, 8 and 16 lock partitions.
Isn't having more lock partitions than
Marshall, Steve [EMAIL PROTECTED] writes:
I want to be able to tell a backend to reinitialize some of the cached
data it is holding in static variables. Generally I want to do this
when the something cached in memory has gotten out-of-sync with what
is in the database. The two examples that
Mark Dilger wrote:
Tom Lane wrote:
Mark Dilger [EMAIL PROTECTED] writes:
... The argument made upthread that a quadratic number of conversion
operators is necessitated doesn't seem right to me, given that each
type could upcast to the canonical built in type. (int1 = smallint,
int3 =
Mark Dilger [EMAIL PROTECTED] writes:
int1 works perfectly, as far as I can tell. int3 works great in memory,
but can't be stored to a table. The problem seems to be that
store_att_byval allows data of size 1 byte but not size 3 bytes, forcing
me to pass int3 by reference. But when I
I see a number of non-ASCII characters in the names of patch submitters
in the CVS logs. Does anyone know a good way to have all these get the
same encoding in the CVS commit logs? I am thinking that is impossible
because we can't attach the email encoding to the commit message.
--
Bruce
Bruce Momjian [EMAIL PROTECTED] writes:
I guess the question is whether it is possible using cvs2cl to show only
HEAD, and then show if the same commit message also appears in the most
recent back branch.
It's so rare that we make a back-branch patch without a corresponding
HEAD patch that I'm
Jim Nasby [EMAIL PROTECTED] writes:
Isn't having more lock partitions than buffer partitions pointless?
AFAIK they're pretty orthogonal. It's true though that a typical
transaction doesn't hold all that many locks, which is why I don't
see a need for a large number of lock partitions.
Jim Nasby wrote:
That's something I'd be willing to do. And for many people that aren't
committers but are still trusted in the community, we could probably
bypass the checking.
That's a worthwhile point. How many patches come from the general
community vs out of the blue? Patches from
Gregory Stark wrote:
Ron Mayer [EMAIL PROTECTED] writes:
...vastly overestimate the number of pages .. because postgresql's guess
at the correlation being practically 0 despite the fact that the distinct
values for any given column are closely packed on a few pages.
I think we need a
Ron Mayer [EMAIL PROTECTED] writes:
I'm wildly guessing that, the # of pages itself seems to be
a bigger factor than the sequential/random nature.
No, they're both important: fetching N pages in sequence is way cheaper
than fetching the same number of pages scattered all over. This is
partly
But forcing a reload of pltcl.so is nothing but a kluge --- it leaks
memory like there's no tomorrow, and it's only an accident that it fails
to crash. I don't want to design a further kluge on top of it.
Are you saying that pltcl.so leaks memory in general, or that forcing a
reload of the
Guillaume Smet [EMAIL PROTECTED] writes:
On 9/13/06, Tom Lane [EMAIL PROTECTED] wrote:
statement: querystring Simple Query
parse stmt: querystring Parse
bind stmt/portal: querystring Bind
execute stmt/portal: querystringExecute
I agree with that.
On Wed, 13 Sep 2006, Tom Dunstan wrote:
Another possibility would be to test these patches in some kind of virtual
machine that gets blown away every X days, so that even if someone did get
something malicious in there it wouldn't last long.
Or just have a snapshot which is reverted after
Marshall, Steve [EMAIL PROTECTED] writes:
But forcing a reload of pltcl.so is nothing but a kluge --- it leaks
memory like there's no tomorrow, and it's only an accident that it fails
to crash. I don't want to design a further kluge on top of it.
Are you saying that pltcl.so leaks memory in
Ron Mayer wrote:
Gregory Stark wrote:
Ron Mayer [EMAIL PROTECTED] writes:
...vastly overestimate the number of pages .. because postgresql's guess
at the correlation being practically 0 despite the fact that the distinct
values for any given column are closely packed on a few pages.
Albe Laurenz [EMAIL PROTECTED] writes:
The patch did not work for me :-(
Is libpq.so in a non-standard directory? If yes, one either
has to export LIBPATH in the environment or link with
-L/location/of/libpq for the executable to find it
(similar to RPATH in Linux).
libpq will definitely be
Bruce Momjian wrote:
I see a number of non-ASCII characters in the names of patch submitters
in the CVS logs. Does anyone know a good way to have all these get the
same encoding in the CVS commit logs? I am thinking that is impossible
because we can't attach the email encoding to the commit
Alvaro Herrera [EMAIL PROTECTED] writes:
I think the best you could do is post the non-ASCII names here, and have
affected people post back their names in HTML escaping or something that
suits the SGML docs.
That's probably the best way to close the loop. I know that when I'm
committing such
Greg Sabino Mullane [EMAIL PROTECTED] writes:
... I can't think of a use case where a user would not want to
append a is_visible clause to the query above. That or start
tracking which pg_temp_ schema belongs to whom.
Well, I'm still having a problem with this, because it seems like a
pretty
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (Jim Nasby) wrote:
I'd love to have the ability to control toasting thresholds
manually. ... Being able to force a field to be
toasted before it normally would could drastically improve tuple
density without requiring the developer to use
Alvaro Herrera wrote:
Bruce Momjian wrote:
I see a number of non-ASCII characters in the names of patch submitters
in the CVS logs. Does anyone know a good way to have all these get the
same encoding in the CVS commit logs? I am thinking that is impossible
because we can't attach the
Jeremy Drake wrote:
On Wed, 13 Sep 2006, Tom Dunstan wrote:
I was under the impression that most VM products are x86 centric, which
wouldn't lead to huge amounts of diversity in the buildfarm results. At least,
not as far as architecture goes.
I have played with QEmu (www.qemu.org) which is
Joshua Reich [EMAIL PROTECTED] writes:
I lurk... I don't know if I'm a 'statistics jock', but I may be
valuable if only I had a better understanding of how the optimizer
works. I have been following this thread with interest, but could really
do with a good pointer to background
Tom Lane wrote:
Mark Dilger [EMAIL PROTECTED] writes:
int1 works perfectly, as far as I can tell. int3 works great in memory,
but can't be stored to a table. The problem seems to be that
store_att_byval allows data of size 1 byte but not size 3 bytes, forcing
me to pass int3 by reference.
I wrote:
... it seems like in the
case where RecordSubTransactionCommit detects that the subxact has not
stored its XID anywhere, we could immediately remove the XID from
the PGPROC array, just as if it had aborted. This would avoid chewing
subxid slots for cases such as exception blocks in
There are several entries on the 8.2 open-items list that I think can be
removed:
Fix backward array comparison - subset
Done (this was redundant with the containment-operator item)
Store only active XIDs in subtransaction cache
Per my note just now, this probably should wait
Mark Dilger [EMAIL PROTECTED] writes:
Tom Lane wrote:
Please provide a stack trace --- AFAIK there shouldn't be any reason why
a pass-by-ref 3-byte type wouldn't work.
(gdb) bt
#0 0xb7e01d45 in memcpy () from /lib/libc.so.6
#1 0x08077ece in heap_fill_tuple (tupleDesc=0x83c2ef7,
Tom Lane wrote:
Mark Dilger [EMAIL PROTECTED] writes:
Tom Lane wrote:
Please provide a stack trace --- AFAIK there shouldn't be any reason why
a pass-by-ref 3-byte type wouldn't work.
(gdb) bt
#0 0xb7e01d45 in memcpy () from /lib/libc.so.6
#1 0x08077ece in heap_fill_tuple
In production today (8.1.4), I ran into a backend process that
wouldn't cancel right away -- minutes went by.
It was in
[0] TransactionIdIsCurrentTransactionId
[1] HeapTupleSatisfiesSnapshot
...
But the interesting thing is that there were 4.6 million elements in
the s-childXids list.
Tom Lane wrote:
I'm having a hard time getting excited about improving this query when
it's so badly coded in the first place. What's an ORDER BY doing in
an EXISTS subquery? The LIMIT is unnecessary too. And the inner WHERE
says nothing so much as I don't know how to design a database
Here is an early draft of the release notes. It needs more polish and
review:
http://momjian.us/cgi-bin/pgrelease
I will catch up on my email tomorrow, update the open items list for
8.2, and then return to the release notes for cleanup.
--
Bruce Momjian [EMAIL PROTECTED]
84 matches
Mail list logo
