Simon Riggs wrote:
On Wed, 2008-01-30 at 18:42 +, Heikki Linnakangas wrote:
It's even worse than that. Elsewhere in this thread Simon mentioned a
partitioned table, where each partition on its own is smaller than the
threshold, but you're seq scanning several partitions and the total size
On Wed, 2008-01-30 at 13:07 -0500, Tom Lane wrote:
> "Zeugswetter Andreas ADI SD" <[EMAIL PROTECTED]> writes:
> > One more question. It would be possible that a session that turned off
> > the synchronized_seqscans still be a pack leader for other later
> > sessions.
> > Do/should we consider that
"Zeugswetter Andreas ADI SD" <[EMAIL PROTECTED]> writes:
> One more question. It would be possible that a session that turned off
> the synchronized_seqscans still be a pack leader for other later
> sessions.
> Do/should we consider that ?
Seems like a reasonable thing to consider ... for 8.4. I'
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Hmm, if you guys are going to add another GUC variable, please hurry
> because we have to translate the description text.
Yeah, I'm going to put it in today --- just the on/off switch.
Any discussions of exposing threshold parameters will have to wait
f
Zeugswetter Andreas ADI SD escribió:
>
> > > The plural seems better to me; there's no such thing as a solitary
> > > synchronized scan, no? The whole point of the feature is to affect
> > > the behavior of multiple scans.
> >
> > +1. The plural is important IMHO.
>
> ok, good.
Hmm, if you guy
On Wed, Jan 30, 2008 at 10:56:47AM +0100, Zeugswetter Andreas ADI SD wrote:
>
> > > The plural seems better to me; there's no such thing as a solitary
> > > synchronized scan, no? The whole point of the feature is to affect
> > > the behavior of multiple scans.
> >
> > +1. The plural is importan
> > The plural seems better to me; there's no such thing as a solitary
> > synchronized scan, no? The whole point of the feature is to affect
> > the behavior of multiple scans.
>
> +1. The plural is important IMHO.
ok, good.
> As I stated earlier, I don't really like this argument (we already
On Jan 29, 2008 8:09 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Zeugswetter Andreas ADI SD" <[EMAIL PROTECTED]> writes:
> > synchronize[d]_seqscan sounds a bit better in my ears than the plural
> > synchronize_seqscans.
>
> The plural seems better to me; there's no such thing as a solitary
> synchr
Ron Mayer <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
> Or is someone prepared to argue that there are no applications out
> there that will be broken if the same query, against the same unchanging
> table, yields different results from one trial to the next?
>
> Won't even autovacuum "analyze"
Tom Lane wrote:
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
Tom Lane <[EMAIL PROTECTED]> wrote:
Or is someone prepared to argue that there are no applications out
there that will be broken if the same query, against the same unchanging
table, yields different results from one trial to
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> wrote:
>> Or is someone prepared to argue that there are no applications out
>> there that will be broken if the same query, against the same unchanging
>> table, yields different results from one trial to the next?
> If
>>> On Tue, Jan 29, 2008 at 1:09 PM, in message <[EMAIL PROTECTED]>,
Tom Lane <[EMAIL PROTECTED]> wrote:
> Or is someone prepared to argue that there are no applications out
> there that will be broken if the same query, against the same unchanging
> table, yields different results from one trial
"Zeugswetter Andreas ADI SD" <[EMAIL PROTECTED]> writes:
> synchronize[d]_seqscan sounds a bit better in my ears than the plural
> synchronize_seqscans.
The plural seems better to me; there's no such thing as a solitary
synchronized scan, no? The whole point of the feature is to affect
the behavi
On Tue, 2008-01-29 at 10:55 +, Gregory Stark wrote:
> "Zeugswetter Andreas ADI SD" <[EMAIL PROTECTED]> writes:
>
> > Sorry, but I don't grok this at all. Why the heck would we care if we have 2
> > parts of the table perfectly clustered, because we started in the middle ?
> > Surely our stats
> > +1. If we go with 'enable_sync_seqcans' for 8.3, and in a future
release
> > cycle we do test the cases Simon described above and we agree we
need to
> > do a fine tune to benefit from this feature, we will need to
deprecate
> > 'enable_sync_seqscans' and invent another one
(sync_seqscans_t
Euler Taveira de Oliveira <[EMAIL PROTECTED]> writes:
> +1. If we go with 'enable_sync_seqcans' for 8.3, and in a future release
> cycle we do test the cases Simon described above and we agree we need to
> do a fine tune to benefit from this feature, we will need to deprecate
> 'enable_sync_seqs
On Tue, Jan 29, 2008 at 10:40:40AM +0100, Zeugswetter Andreas ADI SD wrote:
>
> > It's a good point that we don't want pg_dump to screw up the cluster
> > order, but that's the only use case I've seen this far for disabling
> > sync scans. Even that wouldn't matter much if our estimate for
> >
Simon Riggs wrote:
And if you have a partitioned table with partitions inconveniently
sized? You'd need to *reduce* shared_buffers specifically to get synch
scans and BAS to kick in. Or increase partition size. Both of which
reduce the impact of the benefits we've added.
I don't think the argum
"Zeugswetter Andreas ADI SD" <[EMAIL PROTECTED]> writes:
> Sorry, but I don't grok this at all. Why the heck would we care if we have 2
> parts of the table perfectly clustered, because we started in the middle ?
> Surely our stats collector should recognize such a table as perfectly
> clustered.
> It's a good point that we don't want pg_dump to screw up the cluster
> order, but that's the only use case I've seen this far for disabling
> sync scans. Even that wouldn't matter much if our estimate for
> "clusteredness" didn't get screwed up by a table that looks
> like this:
> "5 6 7 8
Jeff Davis wrote:
> On Mon, 2008-01-28 at 23:13 +, Heikki Linnakangas wrote:
>
>> "clusteredness" didn't get screwed up by a table that looks like this:
>> "5 6 7 8 9 1 2 3 4"
>>
> ...test table with a similar
> distribution to your example, and it shows a correlation of about -0.5,
>
On Mon, 2008-01-28 at 23:13 +, Heikki Linnakangas wrote:
> Tables that are seq scanned are typically very small, like a summary
> table with just a few rows, or huge tables in a data warehousing
> system. Between the extremes, I don't think the threshold actually has
> a very big impact.
And
On Mon, 2008-01-28 at 23:13 +, Heikki Linnakangas wrote:
> It's a good point that we don't want pg_dump to screw up the cluster
> order, but that's the only use case I've seen this far for disabling
> sync scans. Even that wouldn't matter much if our estimate for
> "clusteredness" didn't get
Simon Riggs wrote:
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
24 matches
Mail list logo
