2013/2/19 Bastiaan Olij :
> Hi Andy,
>
> I've tried that with the same result. One subquery works beautifully,
> two subqueries with an OR and it starts to do a sequential scan...
try to rewrite OR to two SELECTs joined by UNION ALL
Pavel
>
> Thanks,
>
> Bastiaan Olij
>
> On 19/02/13 6:31 PM, An
Hi Andy,
I've tried that with the same result. One subquery works beautifully,
two subqueries with an OR and it starts to do a sequential scan...
Thanks,
Bastiaan Olij
On 19/02/13 6:31 PM, Andy wrote:
> Limit the sub-queries to 1, i.e. :
>
> select 1 from Table2 where Table2.ForeignKey = Table1
Limit the sub-queries to 1, i.e. :
select 1 from Table2 where Table2.ForeignKey = Table1.PrimaryKey fetch first 1
rows only
Andy.
On 19.02.2013 07:34, Bastiaan Olij wrote:
Hi All,
Hope someone can help me a little bit here:
I've got a query like the following:
--
select Column1, Column2, Co
Hi All,
Hope someone can help me a little bit here:
I've got a query like the following:
--
select Column1, Column2, Column3
from Table1
where exists (select 1 from Table2 where Table2.ForeignKey =
Table1.PrimaryKey)
or exists (select 1 from Table3 where Table3.ForeignKey = Table1.PrimaryKey)
--
On 19/02/13 13:39, Josh Berkus wrote:
Scott,
So do you have generally slow IO, or is it fsync behavior etc?
All tests except pgBench show this system as superfast. Bonnie++ and DD
tests are good (200 to 300mb/s), and test_fsync shows 14K/second.
Basically it has no issues until checkpoint kic
On Mon, Feb 18, 2013 at 5:39 PM, Josh Berkus wrote:
> Scott,
>
>> So do you have generally slow IO, or is it fsync behavior etc?
>
> All tests except pgBench show this system as superfast. Bonnie++ and DD
> tests are good (200 to 300mb/s), and test_fsync shows 14K/second.
> Basically it has no is
> Did you try turning barriers on or off *manually* (explicitly)? With
> LSI and barriers *on* and ext4 I had less-optimal performance. With
> Linux MD or (some) 3Ware configurations I had no performance hit.
They're off in fstab.
/dev/sdd1 on /data type xfs (rw,noatime,nodiratime,nobarrier)
-
On Mon, Feb 18, 2013 at 6:39 PM, Josh Berkus wrote:
> Scott,
>
>> So do you have generally slow IO, or is it fsync behavior etc?
>
> All tests except pgBench show this system as superfast. Bonnie++ and DD
> tests are good (200 to 300mb/s), and test_fsync shows 14K/second.
> Basically it has no is
Scott,
> So do you have generally slow IO, or is it fsync behavior etc?
All tests except pgBench show this system as superfast. Bonnie++ and DD
tests are good (200 to 300mb/s), and test_fsync shows 14K/second.
Basically it has no issues until checkpoint kicks in, at which time the
entire system
So, our drop in performance is now clearly due to pathological OS
behavior during checkpoints. Still trying to pin down what's going on,
but it's not system load; it's clearly related to the IO system.
Anyone else see this? I'm getting it both on 3.2 and 3.4. We're using
LSI Megaraid.
--
Jos
Vitalii wrote
>
> Since cte is already an optimization fence, you can go further and make
> it temporary table.
> Create table;analyze;select should make optimizer's work much easier.
>
Thanks Vitalii - yes, you are right, and I have used that technique on
other cases like this.
How
Since cte is already an optimization fence, you can go further and make it
temporary table.
Create table;analyze;select should make optimizer's work much easier.
18 лют. 2013 18:45, "John Lumby" напис.
>
> On 2012-10-09 23:09:21
> Tom Lane wrote:
> >
>
>
> > re subject Why am I getting great/ter
On 2012-10-09 23:09:21
Tom Lane wrote:
>
> re subject Why am I getting great/terrible estimates with these CTE queries?
> You're assuming the case where the estimate is better is better for a
> reason ... but it's only better as a result of blind dumb luck. The
> outer-level query planner do
13 matches
Mail list logo
