On Wed, 27 Nov 2013 13:04:54 -0500, David Rysdam wrote:
> We deliberately try to keep our queries fairly simple for several
> reasons. This isn't the most complicated, but they don't get much more
> than this. I'll have them start with 10MB and see what they get.
10MB was enough to get that query
On Wed, 27 Nov 2013 13:02:20 -0500, Tom Lane wrote:
> David Rysdam writes:
> >effective_cache_size - 12000MB
> >shared_buffers - 1024MB
> >random_page_cost - is commented out
> >cpu_tuple_cost - commented out
> >work
David Rysdam writes:
> effective_cache_size - 12000MB
> shared_buffers - 1024MB
> random_page_cost - is commented out
> cpu_tuple_cost - commented out
> work_mem - commented out
> I assume you guys already know
On Wed, 27 Nov 2013 11:06:51 -0500, bricklen wrote:
> Has the client ANALYZEd recently? What happens if the client issues
> the following commands before executing the query?
> VACUUM ANALYZE lp.sigs;
> VACUUM ANALYZE lp.mags;
>
> If that doesn't change the plan, could you post the values for
> ef
On Wed, 27 Nov 2013 11:21:09 -0500, Tom Lane wrote:
> DBMS-agnostic frequently means "sucks equally badly on all DBMSes" :-(
We've generally been OK (cf the ~50ms runtime for the same query at our
site), but we also notice problems sooner than our client sometimes does
and can make algorithm impr
David Rysdam wrote
> I'd never heard of Materialize before, so I looked into it. Seems to
> make a virtual table of the subquery so repetitions of the parent query
> don't have to re-do the work. Sounds like it should only help, right?
Forgive any inaccuracies but I'm pretty sure about the followi
David Rysdam writes:
> Sometimes I want to know if I have any orphans in mags, so I do a query
> like this:
> select signum from lp.Mags where signum is not null and signum not
> in (select lp.Sigs.signum from lp.Sigs)
> (I do this as a subquery because we originally had a old Sybase DB
On 11/27/2013 04:56 PM, David Rysdam wrote:
> I've got two tables, sigs and mags. It's a one-to-one relationship, mags
> is just split out because we store a big, less-often-used field
> there. "signum" is the key field.
>
> Sometimes I want to know if I have any orphans in mags, so I do a query
>
On Wed, Nov 27, 2013 at 7:56 AM, David Rysdam wrote:
>
>
> At my client's location, the query is very slow (same table size,
> similar hardware/config, although they are running 9.0.x and I'm on
> 9.2.x). By "slow" I mean like an *hour*. 'explain' has this structure:
>
> Seq scan on mags
>
I've got two tables, sigs and mags. It's a one-to-one relationship, mags
is just split out because we store a big, less-often-used field
there. "signum" is the key field.
Sometimes I want to know if I have any orphans in mags, so I do a query
like this:
select signum from lp.Mags where signum
10 matches
Mail list logo
