On Wed, May 11, 2011 at 4:47 PM, Lucas Madar wrote:
> On 05/11/2011 09:38 AM, Robert Haas wrote:
>>>
>>> However, if I disable seqscan (set enable_seqscan=false), I get the
>>> following plan:
>>>
>>> QUERY PLAN
>>>
>>> Hash Join (cost=10001298843.53..290002337961.71 rows=8643757 w
> It says the sequential scan has a cost that's way too high, and I'm
> presuming that's why it's choosing the extremely slow plan over the much
> faster plan.
Well, not exactly. It's giving you that cost because you disabled
seqscan, which actually just bumps the cost really high:
postgres=# cre
On 05/11/2011 09:38 AM, Robert Haas wrote:
However, if I disable seqscan (set enable_seqscan=false), I get the
following plan:
QUERY PLAN
Hash Join (cost=10001298843.53..290002337961.71 rows=8643757 width=506)
Hash Cond: (f.id = objects.id)
->Append (cost=100
Robert Haas writes:
> A more interesting question is why you're not getting a plan like this:
> Nested Loop
> -> Seq Scan on objects
> -> Append
>-> Index Scan using xxx_pkey on itemXX
>-> Index Scan using yyy_pkey on itemYY
>-> Index Scan using zzz_pkey on itemZZ
Probably because
On Mon, Apr 11, 2011 at 4:11 PM, Lucas Madar wrote:
> I have a database that contains many tables, each with some common
> characteristics. For legacy reasons, they have to be implemented in a way so
> that they are *all* searchable by an older identifier to find the newer
> identifier. To do this
On 04/11/2011 03:11 PM, Lucas Madar wrote:
EXPLAIN ANALYZE SELECT * FROM objects INNER JOIN item f USING ( id );
This scans everything over everything, and obviously takes forever
(there are millions of rows in the objects table, and tens of thousands
in each itemXX table).
What is your const
I have a database that contains many tables, each with some common
characteristics. For legacy reasons, they have to be implemented in a
way so that they are *all* searchable by an older identifier to find the
newer identifier. To do this, we've used table inheritance.
Each entry has an id, as
