Re: still on joining array/inline values was and is: design, ref integrity and performance - Mailing list pgsql-general

From Ivan Sergio Borgonovo
Subject Re: still on joining array/inline values was and is: design, ref integrity and performance
Date
Msg-id 20091028164835.7f60c708@dawn.webthatworks.it
Whole thread Raw
In response to Re: still on joining array/inline values was and is: design, ref integrity and performance  (Peter Hunsberger <peter.hunsberger@gmail.com>)
List pgsql-general
On Wed, 28 Oct 2009 10:12:19 -0500
Peter Hunsberger <peter.hunsberger@gmail.com> wrote:

> > The first approach requires a distinct/group by that may be
> > expensive.
> > The second one requires I keep in memory all the emails while the
> > first statement run.

> Unless you're dealing with 100,000's of these things I think you're
> engaging in a process of "premature optimization".  Group by can
> work efficiently over millions of rows.

We may get in the range of half that number occasionally but not
feeding emails directly from a HTTP request.
Still the number of passwords generated in one run may be in the
range of 50K. But well I could calmly wait 2 or 3 seconds.
Making some very rough test on a similar box to the one I'll have to
use it takes few milliseconds on a not indexed table.

> Do the simplest thing possible.  Get it working, then see if you
> have any new problems you need to solve.  Every issue you've
> described so far is database design 101 and should present no real
> problem.  I think you're agonizing over nothing...

That's always a good advice. Sometimes you're out just for moral
support.

thanks

--
Ivan Sergio Borgonovo
http://www.webthatworks.it


pgsql-general by date:

Previous
From: Merlin Moncure
Date:
Subject: Re: could not find array type for data type character varying[]
Next
From: Jaime Casanova
Date:
Subject: Re: auto truncate/vacuum full