Laurent Martelli <[EMAIL PROTECTED]> writes:
> PFC>SELECT owner from pictures group by owner;
>
> That's a slight improvement, but there's still a seq scan on pictures:
It should be a sequential scan. An index will be slower.
> HashAggregate (cost=114.38..114.38 rows=21 width=4) (ac
> I just wished there was a means to fully automate all this and render
> it transparent to the user, just like an index.
>
> Merlin> Voila! Merlin p.s. normalize your data always!
>
> I have this:
>
> pictures(
> PictureID serial PRIMARY KEY,
> Owner integer NOT NULL REFERENCES users
On Wed, 2005-03-16 at 19:31 +0100, Laurent Martelli wrote:
> > "Rod" == Rod Taylor <[EMAIL PROTECTED]> writes:
>
> Rod> On Wed, 2005-03-16 at 18:58 +0100, Laurent Martelli wrote:
> >> Consider this query:
> >>
> >> SELECT distinct owner from pictures;
>
> Rod> The performance has n
> "Merlin" == Merlin Moncure <[EMAIL PROTECTED]> writes:
>> Consider this query:
>>
>> SELECT distinct owner from pictures;
Merlin> [...]
>> Any ideas, apart from more or less manually maintaining a list of
>> distinct owners in another table ?
Merlin> you answered your own qu
Wow, what a fast response !!!
> "PFC" == PFC <[EMAIL PROTECTED]> writes:
PFC> Try :
PFC> SELECT owner from pictures group by owner;
That's a slight improvement, but there's still a seq scan on pictures:
HashAggregate (cost=114.38..114.38 rows=21 width=4) (actual time=7.585..7.605
> "Rod" == Rod Taylor <[EMAIL PROTECTED]> writes:
Rod> On Wed, 2005-03-16 at 18:58 +0100, Laurent Martelli wrote:
>> Consider this query:
>>
>> SELECT distinct owner from pictures;
Rod> The performance has nothing to do with the number of rows
Rod> returned, but rather the comple
> Consider this query:
>
> SELECT distinct owner from pictures;
[...]
> Any ideas, apart from more or less manually maintaining a list of
> distinct owners in another table ?
you answered your own question. With a 20 row owners table, you should
be directing your efforts there group by is faste
On Wed, 2005-03-16 at 18:58 +0100, Laurent Martelli wrote:
> Consider this query:
>
> SELECT distinct owner from pictures;
The performance has nothing to do with the number of rows returned, but
rather the complexity of calculations and amount of data to sift through
in order to find it.
> Any
Try :
SELECT owner from pictures group by owner;
Any ideas, apart from more or less manually maintaining a list of
distinct owners in another table ?
That would be a good idea too for normalizing your database.
---(end of broadcast)---
Consider this query:
SELECT distinct owner from pictures;
Unique (cost=361.18..382.53 rows=21 width=4) (actual time=14.197..17.639
rows=21 loops=1)
-> Sort (cost=361.18..371.86 rows=4270 width=4) (actual
time=14.188..15.450 rows=4270 loops=1)
Sort Key: "owner"
-> Seq
10 matches
Mail list logo
