On Sun, 2008-01-27 at 13:37 -0500, Tom Lane wrote:
> Also, does anyone object to making pg_dump just disable it
> unconditionally? Greg's original gripe only mentioned the case of
> clustered tables, but it'd be kind of a pain to make pg_dump turn it
> on and off again for different tables. And I
On Sun, 2008-01-27 at 15:02 +, Gregory Stark wrote:
> It occurred to me the other day that synchronized scans could play havoc with
> clustered tables. When you dump and reload a table even if it was recently
> clustered if any other sequential scans are happening in the system at the
> time yo
On Sun, 2008-01-27 at 12:45 -0500, Tom Lane wrote:
> Maybe a GUC variable to enable/disable syncscan?
The first iterations of the patch included a GUC.
I don't have any objection to re-introducing a GUC to enable/disable it.
However, I would suggest that it defaults to "on", because:
1. There a
Steve Atkins wrote:
On Jan 28, 2008, at 8:36 AM, Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Kevin Grittner wrote:
It would seem reasonable to me for pg_dump to use ORDER BY to select
data from clustered tables.
What will be the performance hit from doing that?
That worrie
>>> On Mon, Jan 28, 2008 at 10:36 AM, in message <[EMAIL PROTECTED]>,
Tom Lane <[EMAIL PROTECTED]> wrote:
> in general pg_dump's charter is to reproduce
> the state of the database as best it can, not to "improve" it.
Seems that I've often seen it recommended as a way to eliminate bloat.
It se
On Jan 28, 2008, at 8:36 AM, Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Kevin Grittner wrote:
It would seem reasonable to me for pg_dump to use ORDER BY to select
data from clustered tables.
What will be the performance hit from doing that?
That worries me too. Also, in
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Kevin Grittner wrote:
>> It would seem reasonable to me for pg_dump to use ORDER BY to select
>> data from clustered tables.
> What will be the performance hit from doing that?
That worries me too. Also, in general pg_dump's charter is to reproduce
th
"Guillaume Smet" <[EMAIL PROTECTED]> writes:
> It was my first idea but I didn't propose it as it's really a
> different thing IMHO. enable_* variables don't change the way
> PostgreSQL really does the job as synchronize_scans (or whatever the
> name will be) does.
> And it's not very consistent wi
>>> On Mon, Jan 28, 2008 at 9:00 AM, in message <[EMAIL PROTECTED]>,
Andrew Dunstan <[EMAIL PROTECTED]> wrote:
> Kevin Grittner wrote:
> On Sun, Jan 27, 2008 at 9:02 AM, in message
>> <[EMAIL PROTECTED]>, Gregory Stark <[EMAIL PROTECTED]>
>> wrote:
>>
>>> Perhaps we should have some form
Kevin Grittner wrote:
On Sun, Jan 27, 2008 at 9:02 AM, in message
<[EMAIL PROTECTED]>, Gregory Stark <[EMAIL PROTECTED]>
wrote:
Perhaps we should have some form of escape hatch for pg_dump to request real
physical order when dumping clustered tables.
It would seem reaso
>>> On Sun, Jan 27, 2008 at 9:02 AM, in message
<[EMAIL PROTECTED]>, Gregory Stark <[EMAIL PROTECTED]>
wrote:
> Perhaps we should have some form of escape hatch for pg_dump to request real
> physical order when dumping clustered tables.
It would seem reasonable to me for pg_dump to use ORDER
Hi Florian,
Glad to see you back!
On Jan 28, 2008 3:25 PM, Florian G. Pflug <[EMAIL PROTECTED]> wrote:
> How about enable_syncscan, or enable_seqscan_sync? It's not strictly
> something the influences the planner, but maybe it's similar enough to
> justify a similar naming?
It was my first idea
Guillaume Smet wrote:
On Jan 27, 2008 9:07 PM, Markus Bertheau
<[EMAIL PROTECTED]> wrote:
2008/1/28, Tom Lane <[EMAIL PROTECTED]>:
Do we have nominations for a name? The first idea that comes to
mind is "synchronized_scanning" (defaulting to ON).
"synchronized_sequential_scans" is a bit long,
On Jan 27, 2008 9:07 PM, Markus Bertheau <[EMAIL PROTECTED]> wrote:
> 2008/1/28, Tom Lane <[EMAIL PROTECTED]>:
> >
> > Do we have nominations for a name? The first idea that comes to mind
> > is "synchronized_scanning" (defaulting to ON).
>
> "synchronized_sequential_scans" is a bit long, but cont
2008/1/28, Tom Lane <[EMAIL PROTECTED]>:
>
> Do we have nominations for a name? The first idea that comes to mind
> is "synchronized_scanning" (defaulting to ON).
"synchronized_sequential_scans" is a bit long, but contains the
keyword "sequential scans", which will ring a bell with many, more so
On Jan 27, 2008 7:37 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Also, does anyone object to making pg_dump just disable it
> unconditionally? Greg's original gripe only mentioned the case of
> clustered tables, but it'd be kind of a pain to make pg_dump turn it
> on and off again for different tabl
"Guillaume Smet" <[EMAIL PROTECTED]> writes:
>>> Maybe a GUC variable to enable/disable syncscan?
> If so, it seems like a good idea even if it's just for debugging purposes.
Do we have nominations for a name? The first idea that comes to mind
is "synchronized_scanning" (defaulting to ON).
Also
On Jan 27, 2008 7:14 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> It could be PGC_USERSET, afaics.
If so, it seems like a good idea even if it's just for debugging purposes.
--
Guillaume
---(end of broadcast)---
TIP 4: Have you searched our list archi
"Guillaume Smet" <[EMAIL PROTECTED]> writes:
> Would it need a restart and be a global GUC variable or
> could it be set temporarily per session?
It could be PGC_USERSET, afaics.
regards, tom lane
---(end of broadcast)---
TI
On Jan 27, 2008 6:45 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Yeah, Rae Steining was complaining to me about that off-list a few weeks
> ago. The whole syncscan behavior risks breaking many apps that "always
> worked before", even if they were disregarding the letter of the SQL spec.
>
> Maybe a
Gregory Stark <[EMAIL PROTECTED]> writes:
> Perhaps we should have some form of escape hatch for pg_dump to request real
> physical order when dumping clustered tables.
Yeah, Rae Steining was complaining to me about that off-list a few weeks
ago. The whole syncscan behavior risks breaking many ap
21 matches
Mail list logo
