marcin mank writes:
> This is pretty off-topic, but if we had some upper bound on the cost
> of the complete plan, we could discard pieces of the plan that already
> cost more.
> One way to get the upper bound is to generate the plan in depth-first
> fashion, instead of the current breadth-first.
Jeff Davis wrote:
All I mean is that the second argument to
COPY should produce/consume bytes and not records. I'm not discussing
the internal implementation at all, only semantics.
In other words, STDIN is not a source of records, it's a source of
bytes; and likewise for STDOUT.
In the conte
Robert Haas writes:
> On Mon, Nov 9, 2009 at 1:10 PM, Tom Lane wrote:
>> Yowza. 18000 distinct paths for one relation? Could we see the test
>> case?
> Hey, wait a minute. Unless I'm missing something, the items being
> accumulated here are not paths (as Tom said upthread and I naively
> beli
On Sat, Nov 28, 2009 at 12:04 AM, Tom Lane wrote:
> It's not so much so-many-paths as so-many-join-relations that's killing
> it. I put some instrumentation into join_search_one_level to count the
> number of joinrels it was creating, and got this before getting bored:
This is pretty off-topic
On Fri, Nov 27, 2009 at 3:05 PM, Robert Haas wrote:
> On Mon, Nov 9, 2009 at 1:42 PM, Robert Haas wrote:
>> On Mon, Nov 9, 2009 at 1:10 PM, Tom Lane wrote:
>>> Robert Haas writes:
On Mon, Nov 9, 2009 at 10:57 AM, Tom Lane wrote:
> Too bad you don't have debug symbols ... it'd be inter
Review comments:
* I attached some documentation suggestions.
* The patch should be merged with CVS HEAD. The changes required are
minor; but notice that there is a minor style difference in the assert
in vacuum().
* vacuumdb should reject -i without -f
* The replace or inplace option is a "ma
Robert Haas writes:
> I guess it's somewhat unsurprising that you can make the planner get
> into trouble with the above settings - we've been over that ground
> before. But it might be possibly interesting that such a simple
> schema is capable of generating so many paths.
It's not so much so-m
On fre, 2009-11-27 at 10:22 -0500, Tom Lane wrote:
> Peter Eisentraut writes:
> > + printfPQExpBuffer(errorMessage,
> > + libpq_gettext("ERROR: service
> > \"%s\" not found\n"), service);
>
> Please make the message consistent with the rest o
Stefan Kaltenbrunner writes:
> Tom Lane wrote:
>> The discussion I saw suggested that you need such a patch at both ends.
> and likely requires a restart of both postgresql and slony afterwards...
Actually, after looking through the available info about this:
https://svn.resiprocate.org/rep/ietf
Tom Lane wrote:
Dave Cramer writes:
Tom Lane wrote:
Install the updated openssl library. Why are you bugging us about
an openssl patch?
After applying the updated openssl library slony dies, presumably
because the server requests a new session key
The discussion I saw suggested that you
Dave Cramer writes:
> Tom Lane wrote:
>> Install the updated openssl library. Why are you bugging us about
>> an openssl patch?
> After applying the updated openssl library slony dies, presumably
> because the server requests a new session key
The discussion I saw suggested that you need such a
Tom Lane wrote:
> Dave Cramer writes:
>
>> Recently openssl has been patched to not renegotiate keys.
>> http://www.links.org/?p=780
>> After a certain amount of data has gone through a postgresql connection
>> the server will attempt to switch session keys.
>> What is the workaround (if any )
Dave Cramer writes:
> Recently openssl has been patched to not renegotiate keys.
> http://www.links.org/?p=780
> After a certain amount of data has gone through a postgresql connection
> the server will attempt to switch session keys.
> What is the workaround (if any ) to avoid this in postgresql
Recently openssl has been patched to not renegotiate keys.
http://www.links.org/?p=780
After a certain amount of data has gone through a postgresql connection
the server will attempt to switch session keys.
What is the workaround (if any ) to avoid this in postgresql ?
Dave
--
Sent via pgsql
On Fri, 2009-11-27 at 13:39 +, Simon Riggs wrote:
> On Tue, 2009-11-24 at 22:13 -0800, Jeff Davis wrote:
>
> > My disagreement with the row-by-row approach is more semantics than
> > performance. COPY translates records to bytes and vice-versa, and your
> > original patch maintains those seman
I wrote:
> I think this is worth doing since it cleans up one of the grottier
> parts of executor initialization. The whole thing around
> ExecContextForcesOids was never pretty, and it's been the source of
> more than one bug if memory serves.
On further review there's a really serious stumbling
Marko Tiikkaja writes:
> Tom Lane wrote:
>> since OIDs in user tables have been deprecated for several versions
>> now, I'm thinking that maybe the case doesn't arise often enough to
>> justify keeping such a wart in the executor.
> Under the circumstances I'd lean towards this option.
I've been
Teodor Sigaev writes:
> Do you suggest to construct that clauses from pathkey representation? And
> append
> constructed clauses to indexquals in create_indexscan_plan?
I'd probably have to read the patch to make any intelligent suggestions
... and right now I'm busy with patches that are alr
Done, IndexScan and IndexPath have separate field to store order clauses.
Why? Isn't that redundant with the pathkey structures? We generate
enough paths during a complex planning problem that I'm not in favor
of adding unnecessary structures to them.
I found two ways to add support of knn-se
On Wed, 2009-11-25 at 13:00 +0200, Heikki Linnakangas wrote:
> I've put up a wiki page with the issues I see with the patch as it
> stands. They're roughly categorized by seriousness.
>
> http://wiki.postgresql.org/wiki/Hot_Standby_TODO
>
> New issues can and probably will still pop up, let's add
Teodor Sigaev writes:
>> Planner (find_usable_indexes function, actually) could push pathkey
>> expression into restriction clauses of index. I'm not fully satisfied
>> with this piece of code, but, may be, someone has a better idea. I
>> though about adding separate indexorderquals in IndexPat
Planner (find_usable_indexes function, actually) could push pathkey
expression into restriction clauses of index. I'm not fully satisfied
with this piece of code, but, may be, someone has a better idea. I
though about adding separate indexorderquals in IndexPath structure...
Done, IndexScan an
Peter Eisentraut writes:
> + printfPQExpBuffer(errorMessage,
> + libpq_gettext("ERROR: service
> \"%s\" not found\n"), service);
Please make the message consistent with the rest of libpq. AFAICS none
of the other messages in that file us
On Tue, 2009-11-24 at 22:13 -0800, Jeff Davis wrote:
> My disagreement with the row-by-row approach is more semantics than
> performance. COPY translates records to bytes and vice-versa, and your
> original patch maintains those semantics.
The bytes <-> records conversion is a costly one. Anythin
On Thu, Nov 26, 2009 at 11:14:54AM -0500, Tom Lane wrote:
> Michael Meskes writes:
> > I wrote a hackish little script that checks if all rules in ecpg.addons are
> > indeed used to create the precompiler's parser to catch renamed symbol and
> > similar changes. Now I wonder whether this should be
On Thu, 2009-11-26 at 08:30 +0200, Heikki Linnakangas wrote:
> I suspect you missed the context of this change. It's about the code
> in tablespc.c, to kill all backends that might have a temporary file
> in a tablespace that's being dropped. It's not about tuple visibility
> but temporary files.
26 matches
Mail list logo
