Hello
this proposal replace older unsuccessful proposal user exception -
http://archives.postgresql.org/pgsql-hackers/2005-06/msg00683.php
It allows only add more parameters to RAISE statement::
syntax:
RAISE [NOTICE|WARNING|EXCEPTION] literal [, params]
[WITH (eparam=expression, ...)];
The hairiness is in the plan dependence (or independence) on parameter
values, ideally we only want to cache plans that would be good for all
parameter values, only the user knows that precisely. Although it could be
possible to examine the column histograms...
If cached plans
If cached plans would be implemented, the dependence on parameter values
could be solved too: use special fork nodes in the plan which execute
different sub-plans depending on special parameter values/ranges,
possibly looking up the stats at runtime, so that the plan is in a
compiled state with
Dear Kris,
am I understanding this correctly that pl/java sets it for the main Java
thread, so other threads spawned by this main thread and using postgres
SPI functionality will run into stack_depth_problems?
I have read only access in this application, so maybe my envisioned
patched version
Heikki Linnakangas wrote:
Ron Mayer wrote:
One use case that I think GIT would help a lot with are my
large address tables that are clustered by zip-code but
often queried by State, City, County, School District,
Police Beat, etc.
I imagine a GIT index on state would just occupy
a couple
Csaba Nagy wrote:
If cached plans would be implemented, the dependence on parameter values
could be solved too: use special fork nodes in the plan which execute
different sub-plans depending on special parameter values/ranges,
possibly looking up the stats at runtime, so that the plan is in a
PFC wrote:
Bind message behaviour was modified :
- If the user asks for execution of a named prepared statement, and the
named statement does not exist in PG's prepared statements cache, instead
of issuing an error and borking the transaction, it Binds to an empty
statement, that takes
Ron Mayer wrote:
Then I wonder if I can conceive of yet another related
index type that'd be useful for such clustered tables. If
I had something like GIT that stored something like
values State='CA' can be found on pages 1000 through 1
and 2 through 21000 would it be even more
On Mon, 2008-04-14 at 16:54 +0300, Heikki Linnakangas wrote:
Figuring out the optimal decision points is hard, and potentially very
expensive. There is one pretty simple scenario though: enabling the use
of partial indexes, preparing one plan where a partial index can be
used, and another
On Mon, 2008-04-14 at 16:10 +0200, Csaba Nagy wrote:
... or plan the query with the actual parameter value you get, and also
record the range of the parameter values you expect the plan to be valid
for. If at execution time the parameter happens to be out of that range,
replan, and possibly
... or plan the query with the actual parameter value you get, and also
record the range of the parameter values you expect the plan to be valid
for. If at execution time the parameter happens to be out of that range,
replan, and possibly add new sublpan covering the extra range. This
could
Awhile back we did some significant rejiggering to ensure that no
relcache load would be attempted without holding at least
AccessShareLock on the relation. (Otherwise, if someone else
is in process of making an update to one of the system catalog
rows defining the relation, there's a race
Bind message behaviour was modified :
- If the user asks for execution of a named prepared statement, and the
named statement does not exist in PG's prepared statements cache,
instead
of issuing an error and borking the transaction, it Binds to an empty
statement, that takes no parameters,
I like cross-session query plan caching talk. I would prefer if the
function was optional (i.e. per-session use cross-session query plan
cache variable).
I like the automatic re-plan if the estimate did not match the actual
idea with some softening technique involved such as if the last 3
On Mon, 2008-04-14 at 10:55 -0400, Mark Mielke wrote:
The other ideas about automatically deciding between plans based on
ranges and such strike me as involving enough complexity and logic, that
to do properly, it might as well be completely re-planned from the
beginning to get the most
On Mon, 14 Apr 2008 16:17:18 +0200, Csaba Nagy [EMAIL PROTECTED] wrote:
On Mon, 2008-04-14 at 16:10 +0200, Csaba Nagy wrote:
... or plan the query with the actual parameter value you get, and also
record the range of the parameter values you expect the plan to be valid
for. If at execution
I have been looking at refining the sorting of objects in pg_dump to
make it take advantage of buffering and synchronised scanning, and
possibly make parallel restoration simpler and more efficient.
My first thought was to sort indexes by namespace, tablename,
indexname instead of by
On Mon, 14 Apr 2008, Alexander Wöhrer wrote:
am I understanding this correctly that pl/java sets it for the main Java
thread, so other threads spawned by this main thread and using postgres
SPI functionality will run into stack_depth_problems?
pljava sets the stack_base_ptr for each thread
On Mon, 2008-04-14 at 17:08 +0200, PFC wrote:
Those Decision nodes could potentially lead to lots of decisions
(ahem).
What if you have 10 conditions in the Where, plus some joined ones ?
That
would make lots of possibilities...
Yes, that's true, but most of them are likely
There has been talk of the lessons we learned during this commit fest,
but exactly what lessons did we learn? I am not clear on that so I
assume others are not as well. What are we going to do differently
during the next commit fest?
--
Bruce Momjian [EMAIL PROTECTED]
On Mon, 2008-04-14 at 11:18 -0400, Andrew Dunstan wrote:
I have been looking at refining the sorting of objects in pg_dump to
make it take advantage of buffering and synchronised scanning, and
possibly make parallel restoration simpler and more efficient.
Synchronized scanning is
Bruce Momjian wrote:
There has been talk of the lessons we learned during this commit fest,
but exactly what lessons did we learn? I am not clear on that so I
assume others are not as well. What are we going to do differently
during the next commit fest?
As far as the Wiki page is
Jeff Davis wrote:
On Mon, 2008-04-14 at 11:18 -0400, Andrew Dunstan wrote:
I have been looking at refining the sorting of objects in pg_dump to
make it take advantage of buffering and synchronised scanning, and
possibly make parallel restoration simpler and more efficient.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Apr 15, 2008 at 2:45 AM, Alvaro Herrera wrote:
As far as the Wiki page is concerned, it would be good to make sure the
entries have a bit more info than just a header line -- things such as
author, who reviewed and what did the reviewer
I've committed the runtime-recheck changes. Oleg had mentioned that
GIST text search could be improved by using runtime rechecking, but
I'll leave any refinements of that sort up to you.
One thing I was wondering about is that GIN and GIST are set up to
preinitialize the recheck flag to TRUE;
Brendan Jurd escribió:
On Tue, Apr 15, 2008 at 2:45 AM, Alvaro Herrera wrote:
As far as the Wiki page is concerned, it would be good to make sure the
entries have a bit more info than just a header line -- things such as
author, who reviewed and what did the reviewer say about it.
Brendan Jurd wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Apr 15, 2008 at 2:45 AM, Alvaro Herrera wrote:
As far as the Wiki page is concerned, it would be good to make sure the
entries have a bit more info than just a header line -- things such as
author, who
Andrew Dunstan [EMAIL PROTECTED] writes:
I should have expressed it better. The idea is to have pg_dump emit the
objects in an order that allows the restore to take advantage of sync
scans. So sync scans being disabled in pg_dump would not at all matter.
Unless you do something to explicitly
Alvaro Herrera [EMAIL PROTECTED] writes:
As far as the Wiki page is concerned, it would be good to make sure the
entries have a bit more info than just a header line -- things such as
author, who reviewed and what did the reviewer say about it.
I think it'd be easy to go overboard there. One
2. If we set the flag TRUE, and that's wrong (ie, the query is really
exact) then a useless recheck occurs when we arrive at the heap.
Nothing visibly goes wrong, but the query is slower than it should be.
4. If we set the flag FALSE, and that's wrong (ie, the query is really
inexact), then
Teodor Sigaev [EMAIL PROTECTED] writes:
By the argument that it's better to break things obviously than to
break them subtly, risking case 4 seems more attractive than risking
case 2.
The single thought is: usually, it's very hard to see that query returns more
results that it should be. It
Tom Lane wrote:
A smaller lesson was that you can't start fest without a queue of
ready-to-work-on patches. We seem to be evolving towards a plan
where stuff gets dumped onto the wiki page more or less immediately
as it comes in. That should take care of that problem, though I'd
still like
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Apr 15, 2008 at 4:12 AM, Tom Lane wrote:
Alvaro Herrera writes:
As far as the Wiki page is concerned, it would be good to make sure the
entries have a bit more info than just a header line -- things such as
author, who reviewed and
Bruce Momjian [EMAIL PROTECTED] writes:
There has been talk of the lessons we learned during this commit fest,
but exactly what lessons did we learn?
Actually, the *main* lesson we learned was don't start with a
2000-email inbox. There were a couple of reasons that the queue
was so forbidding:
Tom Lane wrote:
Teodor Sigaev [EMAIL PROTECTED] writes:
By the argument that it's better to break things obviously than to
break them subtly, risking case 4 seems more attractive than risking
case 2.
The single thought is: usually, it's very hard to see that query returns more
results that
Tom Lane wrote:
the fest, and I think it's unlikely to happen in future either.
We should probably try to limit the focus of fests to consider only
actual patches, with design discussions handled live during normal
development, the way they've always been in the past.
We have discouraged
Tom Lane wrote:
A smaller lesson was that you can't start fest without a queue of
ready-to-work-on patches. We seem to be evolving towards a plan
where stuff gets dumped onto the wiki page more or less immediately
as it comes in. That should take care of that problem, though I'd
still like
Bruce Momjian wrote:
Tom Lane wrote:
the fest, and I think it's unlikely to happen in future either.
We should probably try to limit the focus of fests to consider only
actual patches, with design discussions handled live during normal
development, the way they've always been in the past.
Alvaro Herrera wrote:
Bruce Momjian wrote:
Tom Lane wrote:
the fest, and I think it's unlikely to happen in future either.
We should probably try to limit the focus of fests to consider only
actual patches, with design discussions handled live during normal
development, the way
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
We should probably try to limit the focus of fests to consider only
actual patches, with design discussions handled live during normal
development, the way they've always been in the past.
We have discouraged design discussions during
Bruce Momjian wrote:
Alvaro Herrera wrote:
Perhaps this is a good idea -- discussions on new development should
be deferred until the end of the commitfest, if one is in progress.
We'll see what happens on the May commitfest, but my guess is that it
will be a lot shorter than the March
Alvaro Herrera [EMAIL PROTECTED] writes:
Perhaps this is a good idea -- discussions on new development should
be deferred until the end of the commitfest, if one is in progress.
Well, that was part of the original idea of a commit fest, on the theory
that everyone should be helping
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
We should probably try to limit the focus of fests to consider only
actual patches, with design discussions handled live during normal
development, the way they've always been in the past.
We have discouraged
Tom Lane [EMAIL PROTECTED] writes:
Other lessons that were already brought up:
* Bruce's mbox page was not a good status tool, despite his efforts
to improve it;
* If Bruce and I are the only ones doing anything, it's gonna be slow.
How did you feel about the idea of having a Tom-free
Heikki Linnakangas [EMAIL PROTECTED] writes:
Anybody else have an opinion?
Better slow than wrong in this case.
The better to break obviously than subtly argument doesn't hold here,
because
slow isn't the same as broken, and returning extra incorrect rows isn't
obviously :-).
We're
On Mon, 14 Apr 2008 21:12:59 +0100
Gregory Stark [EMAIL PROTECTED] wrote:
I assume you realize it's not that I don't appreciate having you
doing all this work but I think it would be a good exercise for us to
go through do once. (And you certainly deserve a break!)
Although I applaud the
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
No, changing that wasn't what I meant to suggest. My point here is that
we'd dropped a number of big mushy discussions into the queue with the
idea that they'd be re-opened during commit fest, but new discussion
did not happen to any
Gregory Stark [EMAIL PROTECTED] writes:
We're talking about code which is recompiled for a new version of
Postgres but not altered to return the recheck flag for every tuple?
Can we rig the code so it effectively returns recheck=true all the
time in that case?
That's what we've got now. I
Gregory Stark [EMAIL PROTECTED] writes:
How did you feel about the idea of having a Tom-free commitfest for May?
Not a lot, though certainly I'd be willing to disengage from trivial
patches if someone else picked them up.
One problem with this fest was that a whole lot of the patches *weren't*
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
I should have expressed it better. The idea is to have pg_dump emit the
objects in an order that allows the restore to take advantage of sync
scans. So sync scans being disabled in pg_dump would not at all matter.
Unless you
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Apr 15, 2008 at 6:39 AM, Tom Lane wrote:
Perhaps it would be useful to try to rate pending patches by difficulty?
Just a thought, but the file size of a context diff has a pretty good
correlation to the patch's intrusiveness /
Brendan Jurd escribió:
Anyway, take a look at http://wiki.postgresql.org/wiki/Template:Patch,
and http://wiki.postgresql.org/wiki/User_talk:Direvus for an example
of how it is used. This is my first stab at writing a patch queue
entry template. It uses a similar structure to what's already
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Apr 15, 2008 at 7:00 AM, Alvaro Herrera wrote:
Thanks, I changed a couple of patches to this method, and quickly hacked
up added a new template for reviews.
Re: horizontal whitespace in the patch template, I wonder if we can put
the
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
No, changing that wasn't what I meant to suggest. My point here is that
we'd dropped a number of big mushy discussions into the queue with the
idea that they'd be re-opened during commit fest, but new discussion
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, Mar 21, 2008 at 7:47 AM, Tom Lane wrote:
I didn't do anything about removing A_Const's typename field, but I'm
thinking that would be a good cleanup patch.
Here's my attempt to remove the typename field from A_Const. There
were a few
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Apr 15, 2008 at 2:45 AM, Alvaro Herrera wrote:
Lastly, I would say that pushing submitters to enter their sent patches
into the Wiki worked -- we need to ensure that they keep doing it.
I'd also suggest, if you want to get serious about
I've posted this on pgsql-general and pgsql-sql, and haven't got any
responses. If any of you would be able to take a look at this for me and
give some feedback, I'd be obliged.
I would like to create a rule that, by updating a view, allows me to update
one table and insert into another.
I'm seeing this:
Liste des fonctions
-[ RECORD 1
]+
Schéma | public
Nom | tg_backlink_a
Type de données du résultat| trigger
Type de données
On Mon, Apr 14, 2008 at 5:01 PM, Csaba Nagy [EMAIL PROTECTED] wrote:
On Mon, 2008-04-14 at 10:55 -0400, Mark Mielke wrote:
The other ideas about automatically deciding between plans based on
ranges and such strike me as involving enough complexity and logic, that
to do properly, it might
On Mon, Apr 14, 2008 at 6:45 PM, Alvaro Herrera
[EMAIL PROTECTED] wrote:
[...]
As far as the Wiki page is concerned, it would be good to make sure the
entries have a bit more info than just a header line -- things such as
author, who reviewed and what did the reviewer say about it.
Some
Dawid Kuroczko escribió:
I thought the patch would be trivial, sent it to -patches. Then, later
on I thought that perhaps it should be discussed on the -hackers
nonetheless, so I have written there also:
http://archives.postgresql.org/pgsql-hackers/2008-04/msg00147.php
then the patch got
On Mon, 14 Apr 2008 21:25:28 -0400
Alvaro Herrera [EMAIL PROTECTED] wrote:
The problem is that the patch was initially trivial, but it turned
into a much larger redesign of command handling. I think that's a
great turnout for a submission.
Don't forget to update developer FAQ as well. :)
62 matches
Mail list logo
