Gregory Stark wrote:
"Kris Jurka" <[EMAIL PROTECTED]> writes:
On Mon, 28 Jan 2008, Jeff Davis wrote:
I think that pg_dump is a reasonable use case for synchoronized scans
when the table has not been clustered. It could potentially make pg_dump
have much less of a performance impact when run a
"Kris Jurka" <[EMAIL PROTECTED]> writes:
> On Mon, 28 Jan 2008, Jeff Davis wrote:
>
>> I think that pg_dump is a reasonable use case for synchoronized scans
>> when the table has not been clustered. It could potentially make pg_dump
>> have much less of a performance impact when run against an ac
On Mon, 28 Jan 2008, Jeff Davis wrote:
I think that pg_dump is a reasonable use case for synchoronized scans
when the table has not been clustered. It could potentially make pg_dump
have much less of a performance impact when run against an active
system.
One of the advantages I see with ma
On Sun, 2008-01-27 at 15:07 -0500, 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
Guillaume Smet wrote:
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
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
13 matches
Mail list logo
