Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
OK, but keep in mind if we use synchronized_seqscans in pg_dump we will
have to recognize that GUC forever.
No, because it's being used on the query side, not in the emitted dump.
We have *never* promised that pg_dump version N could
Tom Lane wrote:
in fact, personally I'd like to make that case be a hard error,
rather than something people could override with -i.
+1 to this idea. TODO for 8.4?
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom
On Thu, 2008-01-31 at 11:20 -0300, Alvaro Herrera wrote:
Tom Lane wrote:
in fact, personally I'd like to make that case be a hard error,
rather than something people could override with -i.
+1 to this idea. TODO for 8.4?
-1 without some more planning about the effects and
Hi,
Le jeudi 31 janvier 2008, Tom Lane a écrit :
We have *never* promised that pg_dump version N could dump from server
version N+1 .., in fact, personally I'd like to make that case be a hard
error, rather than something people could override with -i.
Are you thinking about next major or
Dimitri Fontaine wrote:
-- Start of PGP signed section.
Hi,
Le jeudi 31 janvier 2008, Tom Lane a ?crit?:
We have *never* promised that pg_dump version N could dump from server
version N+1 .., in fact, personally I'd like to make that case be a hard
error, rather than something people
Le jeudi 31 janvier 2008, Tom Lane a écrit :
I'm thinking next major. In principle there could be cases where a
minor update could break pg_dump, but it seems unlikely enough that
it's not reasonable to embed such a policy in the code. As for
next major, though, the mere existence of the -i
Dimitri Fontaine [EMAIL PROTECTED] writes:
Le jeudi 31 janvier 2008, Tom Lane a écrit :
We have *never* promised that pg_dump version N could dump from server
version N+1 .., in fact, personally I'd like to make that case be a hard
error, rather than something people could override with -i.
Bruce Momjian [EMAIL PROTECTED] writes:
Dimitri Fontaine wrote:
-- Start of PGP signed section.
Hi,
Le jeudi 31 janvier 2008, Tom Lane a ?crit?:
We have *never* promised that pg_dump version N could dump from server
version N+1 .., in fact, personally I'd like to make that case be a
On Mon, 2008-01-28 at 16:21 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Rather than having a boolean GUC, we should have a number and make the
parameter synchronised_scan_threshold.
This would open up a can of worms I'd prefer not to touch, having to do
with whether the
Simon Riggs [EMAIL PROTECTED] writes:
I'm still not very happy with any of the options here.
BAS is great if you didn't want to trash the cache, but its also
annoying to people that really did want to load a large table into
cache. However we set it, we're going to have problems because not
Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
I'm still not very happy with any of the options here.
BAS is great if you didn't want to trash the cache, but its also
annoying to people that really did want to load a large table into
cache. However we set it, we're going to have
On Wed, 2008-01-30 at 18:42 +, Heikki Linnakangas wrote:
Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
I'm still not very happy with any of the options here.
BAS is great if you didn't want to trash the cache, but its also
annoying to people that really did want to load a
Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
I'm still not very happy with any of the options here.
BAS is great if you didn't want to trash the cache, but its also
annoying to people that really did want to load a large table into
cache. However we set it, we're going to have
Bruce Momjian wrote:
Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
I'm still not very happy with any of the options here.
BAS is great if you didn't want to trash the cache, but its also
annoying to people that really did want to load a large table into
cache. However we
Bruce Momjian [EMAIL PROTECTED] writes:
Another question --- why don't we just turn off synchronized_seqscans
when we do COPY TO? That would fix pg_dump and be transparent.
Enforcing this from the server side seems a pretty bad idea. Note that
there were squawks about having pg_dump behave
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Another question --- why don't we just turn off synchronized_seqscans
when we do COPY TO? That would fix pg_dump and be transparent.
Enforcing this from the server side seems a pretty bad idea. Note that
there were squawks about
Bruce Momjian [EMAIL PROTECTED] writes:
OK, but keep in mind if we use synchronized_seqscans in pg_dump we will
have to recognize that GUC forever.
No, because it's being used on the query side, not in the emitted dump.
We have *never* promised that pg_dump version N could dump from server
I liked the synchronized_sequential_scans idea myself.
I think that's a bit too long. How about synchronized_scans, or
synchronized_seqscans?
We have enable_seqscan already, so that last choice seems to fit in.
Yes looks good, how about synchronized_seqscan without plural ?
Andreas
On Sun, 2008-01-27 at 21:04 -0500, Tom Lane wrote:
[ redirecting thread to -hackers ]
Neil Conway [EMAIL PROTECTED] writes:
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
Simon Riggs [EMAIL PROTECTED] writes:
Rather than having a boolean GUC, we should have a number and make the
parameter synchronised_scan_threshold.
This would open up a can of worms I'd prefer not to touch, having to do
with whether the buffer-access-strategy behavior should track that or
not.
On Jan 28, 2008, at 6:14 PM, Simon Riggs wrote:
On Sun, 2008-01-27 at 21:04 -0500, Tom Lane wrote:
[ redirecting thread to -hackers ]
Neil Conway [EMAIL PROTECTED] writes:
On Sun, 2008-01-27 at 21:54 +, Gregory Stark wrote:
I liked the synchronized_sequential_scans idea myself.
I
On Mon, 2008-01-28 at 16:21 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Rather than having a boolean GUC, we should have a number and make the
parameter synchronised_scan_threshold.
This would open up a can of worms I'd prefer not to touch, having to do
with whether the
[ redirecting thread to -hackers ]
Neil Conway [EMAIL PROTECTED] writes:
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?
We have
On Jan 27, 2008, at 21:04 , Tom Lane wrote:
[ redirecting thread to -hackers ]
Neil Conway [EMAIL PROTECTED] writes:
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,
Michael Glaesemann [EMAIL PROTECTED] writes:
Neil Conway [EMAIL PROTECTED] writes:
I think that's a bit too long. How about synchronized_scans, or
synchronized_seqscans?
Would it make sense to match the plural as well?
Actually, the best suggestion I've seen so far is Guillaume's
25 matches
Mail list logo
