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
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 you dump it the dump could shuffle the records out of order.
No
22 matches
Mail list logo
