Sergei Shelukhin wrote:
This is just an example isolating the problem.
Actual queries contain more tables and more joins and return
reasonable amount of data.
Performance of big indices however is appalling, with planner always
reverting to seqscan with default settings.
I tried to pre-filter th
On 6/7/07, Sergei Shelukhin <[EMAIL PROTECTED]> wrote:
Version is 8.1
The query I originally ran returned ~4-5 rows and had a lot of other
joins and filtering conditions prior to the join with the big table.
Is there any way to instruct postgres to do joins in the specific
order or smth?
make
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Alexander Staubo escribió:
>> Are you sure? I was under the impression that PostgreSQL could reorder
>> "where" clauses, but did not yet reorder explicit joins (as opposed
>> to implicit ones through, say, "in"). But perhaps it only applied to
>> some t
Alexander Staubo escribió:
> On 6/8/07, Martijn van Oosterhout <[EMAIL PROTECTED]> wrote:
> >On Thu, Jun 07, 2007 at 11:20:20AM -0700, Sergei Shelukhin wrote:
> >> Version is 8.1
> >> The query I originally ran returned ~4-5 rows and had a lot of other
> >> joins and filtering conditions prior to t
On 6/8/07, Martijn van Oosterhout <[EMAIL PROTECTED]> wrote:
On Thu, Jun 07, 2007 at 11:20:20AM -0700, Sergei Shelukhin wrote:
> Version is 8.1
> The query I originally ran returned ~4-5 rows and had a lot of other
> joins and filtering conditions prior to the join with the big table.
> Is there
On Thu, Jun 07, 2007 at 11:20:20AM -0700, Sergei Shelukhin wrote:
> Version is 8.1
> The query I originally ran returned ~4-5 rows and had a lot of other
> joins and filtering conditions prior to the join with the big table.
> Is there any way to instruct postgres to do joins in the specific
> orde
Version is 8.1
The query I originally ran returned ~4-5 rows and had a lot of other
joins and filtering conditions prior to the join with the big table.
Is there any way to instruct postgres to do joins in the specific
order or smth?
---(end of broadcast)--
On Sun, Jun 03, 2007 at 11:29:07PM -0700, Sergei Shelukhin wrote:
> I wonder what exactly makes index perform 100+ times slower than
> seqscan - I mean even if it's perfromed on the HD which it should not
> be given the index size, index and table are on the same HD and index
> is smaller and also
This is just an example isolating the problem.
Actual queries contain more tables and more joins and return
reasonable amount of data.
Performance of big indices however is appalling, with planner always
reverting to seqscan with default settings.
I tried to pre-filter the data as much as possible
Sergei Shelukhin escribió:
> explain select * from entries inner join stuff on entries.id =
> stuff.id;
>
> -> Seq Scan on stuff (cost=0.00..193344.00 rows=12550400 width=12)
>
>
> set enable_seqscan = off;
>
> explain select * from entries inner join stuff on entries.id =
> stuff.id;
>
>
Create table entries (id bigint primary key, somedata varchar(500));
/* insert ~12mil rows of data, somedata mostly empty */
create table stuff (id bigint, bah int, primary key (id, bah));
insert into stuff (id,bah) select id, 1 from entries;
create index blah on stuff(id);
vacuum full analyze;
11 matches
Mail list logo
