Hi Russell,
On Jan 28, 2008 7:27 AM, Russell Smith <[EMAIL PROTECTED]> wrote:
> Can somebody explain why it's important to load with
> synchronized_scanning off?
>
> do_sql_command(g_conn, "SET synchronized_scanning TO off");
It's the start point of this patch. See this thread [
http://archives.p
On Mon, 2008-01-28 at 17:27 +1100, Russell Smith wrote:
> Can somebody explain why it's important to load with
> synchronized_scanning off?
*Loading* with synchronized scanning off is not important (and is not
implemented by the patch).
*Dumping* with synchronized scanning off is necessary to en
Tom Lane wrote:
Per today's -hackers discussion, add a GUC variable to allow clients to
disable the new synchronized-scanning behavior, and make pg_dump disable
sync scans so that it will reliably preserve row ordering. This is a
pretty trivial patch, but seeing how late we are in the 8.3 releas
On Sun, 2008-01-27 at 21:54 +, Gregory Stark wrote:
> I liked the "synchronized_sequential_scans" idea myself.
I think that's a bit too long. How about "synchronized_scans", or
"synchronized_seqscans"?
-Neil
---(end of broadcast)---
TIP 6: ex
Gregory Stark <[EMAIL PROTECTED]> writes:
> I liked the "synchronized_sequential_scans" idea myself.
The name is still open for discussion --- it's an easy
search-and-replace in the patch ...
regards, tom lane
---(end of broadcast)-
> >> Per today's -hackers discussion, add a GUC variable to
> allow clients
> >> to disable the new synchronized-scanning behavior, and
> make pg_dump
> >> disable sync scans so that it will reliably preserve row
> ordering.
> >> This is a pretty trivial patch, but seeing how late we are
"Jonah H. Harris" <[EMAIL PROTECTED]> writes:
> On Jan 27, 2008 3:07 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
>> Per today's -hackers discussion, add a GUC variable to allow clients to
>> disable the new synchronized-scanning behavior, and make pg_dump disable
>> sync scans so that it will reliably
On Jan 27, 2008 3:07 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Per today's -hackers discussion, add a GUC variable to allow clients to
> disable the new synchronized-scanning behavior, and make pg_dump disable
> sync scans so that it will reliably preserve row ordering. This is a
> pretty trivial
Per today's -hackers discussion, add a GUC variable to allow clients to
disable the new synchronized-scanning behavior, and make pg_dump disable
sync scans so that it will reliably preserve row ordering. This is a
pretty trivial patch, but seeing how late we are in the 8.3 release
cycle, I thought
On Jan 27, 2008 8:13 PM, Neil Conway <[EMAIL PROTECTED]> wrote:
> (Compare that with the irritation we may well see from the removal of
> implicit casts in 8.3, which will break *far* more applications, for a
> benefit that many users will no doubt find rather hard to observe.)
It's a bit off-topi
On Sun, 2008-01-27 at 12:36 -0500, Tom Lane wrote:
> Both of the above arguments hold water only if we implement compatible
> *semantics*, not merely syntax, so I find them unconvincing at this
> stage.
How are the semantics of the proposed patch incompatible with the SQL
spec or the implementatio
Neil Conway <[EMAIL PROTECTED]> writes:
> (1) This is SQL-standard syntax (and not even wacko syntax, at that!),
> and there is merit in implementing it on those grounds alone.
> (2) It is supported by DB2, MS SQL and Oracle, so there is a further
> compatibility argument to be made.
Both of the a
Gregory Stark <[EMAIL PROTECTED]> writes:
> I still hope to do recursive queries for 8.4 so I don't have strong feelings
> for this part either way.
One question that hasn't been asked is whether this patch is likely to
help, or to get in the way, for a more full-fledged implementation.
I don't re
Hello
On 27/01/2008, Neil Conway <[EMAIL PROTECTED]> wrote:
> On Sun, 2008-01-27 at 09:17 +, Gregory Stark wrote:
> > Tom's feeling at the time was that even though it was providing something
> > from
> > the standard, it wasn't actually allowing the user to do anything he
> > couldn't
> > b
On Sun, 2008-01-27 at 09:17 +, Gregory Stark wrote:
> Tom's feeling at the time was that even though it was providing something from
> the standard, it wasn't actually allowing the user to do anything he couldn't
> before.
I think this feature has value:
(1) This is SQL-standard syntax (and n
"Neil Conway" <[EMAIL PROTECTED]> writes:
> Remaining work is to review the guts of the patch (which shouldn't take
> long), and write documentation and regression tests. I'm personally
> hoping to see this get into the tree fairly early in the 8.4 cycle,
> pending discussion of course.
Note tha
16 matches
Mail list logo
