| From: | Stephen Frost <sfrost(at)snowman(dot)net> |
|---|---|
| To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Sergey Koposov <koposov(at)ast(dot)cam(dot)ac(dot)uk>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile |
| Date: | 2012-05-25 16:17:27 |
| Message-ID: | 20120525161727.GU1267@tamriel.snowman.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
* Merlin Moncure (mmoncure(at)gmail(dot)com) wrote:
> Right -- duh. Well, hm. Is this worth fixing? ISTM there's a bit of
> 'optimizing for pgbench-itis' in the buffer partitions -- they seem
> optimized to lever the mostly random access behavior of pgbench. But
> how likely is it to see multiple simultaneous scans in the real world?
> Interleaving scans like that is not a very effective optimization --
> if it was me, it'd be trying to organize something around a
> partitioned tid scan for parallel sequential access.
Didn't we implement a system whereby this is exactly what we intend to
happen on the read side- that is, everyone doing a SeqScan gangs up on
one ring buffer and follows it, which we felt was going to dramatically
improve performance in some cases?
Or is this completely different from that..?
Thanks,
Stephen
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Janes | 2012-05-25 16:23:09 | Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile |
| Previous Message | Merlin Moncure | 2012-05-25 16:13:32 | Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile |