Rick Otten <rottenwindfish@gmail.com> wrote:
> I'm using PostgreSQL 9.5 Beta 2.
>
> I am working with a partitioned table set.
>
> The first thing I noticed, when creating indexes on the 20 or so partitions,
> was that if I create them too fast they don't all succeed. I have to do a few
> at a time, let them breathe for a few seconds, and then do a few more. I had
> been simply generating all of the create index commands in a text editor, and
> then cutting and pasting the lot of them into psql all at once or running them
> by using psql '-f'. Most would get created, but not all. It seems almost
> random. There were no obvious error messages. When I do a few at a time, it
> is never an issue.
Sure? Have you checked that?
> If I do a simple query with a where clause on a specific column from the parent
> table, I can see it index scan each of the children. This is what I want it to
> do, so no complaints there.
>
> However, if I try to (inner) join another table with that column, the planner
> sequence scans each of the children instead of using the indexes. I saw
> someone had posted a similar question to this list back in January, however I
> didn't see the answer.
Show us the output from explain analyse <your query>
> FWIW, the column in question is a UUID column and is the primary key for each
> of the child tables.
PostgreSQL using a cost-modell, so maybe there are not enough rows in
the table. That's just a guess, you can see that with explain analyse
...
Andreas
--
Really, I'm not out to destroy Microsoft. That will just be a completely
unintentional side effect. (Linus Torvalds)
"If I was god, I would recompile penguin with --enable-fly." (unknown)
Kaufbach, Saxony, Germany, Europe. N 51.05082°, E 13.56889°
