On Mon, Apr 14, 2008 at 06:03:27PM -0400, Chad Showalter wrote:
> 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 saw it there too, but couldn't spot anything at
On Mon, Apr 14, 2008 at 05:15:51PM -0400, Bruce Momjian wrote:
> > > So when/how do those discussions get resolved?
> >
> > [ shrug... ] You can't force ideas to happen on a schedule.
>
> I need is to know if they are ideas worthy of TODO.
One thing I would like is if larger more complex patche
Peter Eisentraut napsal(a):
Bruce Momjian wrote:
That is a nice list, but are these used for bug tracking or patch
tracking?
In my experience, these two concepts become mostly the same. Just one is
classified "normal" or "critical" and the the other is tagged "wishlist"
and "patch" or "atta
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 we
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 g
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.
>
>
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,
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 de
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.
T
-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
-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
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 di
-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
>
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 alrea
-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 / complexi
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
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
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.
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
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
"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
"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-f
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 hav
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 review/co
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
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 discussio
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
> > > developme
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
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 l
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
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 forbid
-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 revi
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
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 shou
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 rows
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.
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 explic
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",
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
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; thi
-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 revi
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.
Synchro
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 conce
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 explic
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]>http://momjia
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 li
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 j
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 indexname> instead of by . However, that doesn't
go f
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 ti
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
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
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, an
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 conditi
> ... 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
> cou
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
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 anot
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 effecti
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
c
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 ta
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 pa
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 (ch
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 wit
> 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
64 matches
Mail list logo
