Re: still on joining array/inline values was and is: design, ref integrity and performance

From: Ivan Sergio Borgonovo <mail(at)webthatworks(dot)it>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: still on joining array/inline values was and is: design, ref integrity and performance
Date: 2009-10-28 15:48:35
Message-ID: 20091028164835.7f60c708@dawn.webthatworks.it
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Wed, 28 Oct 2009 10:12:19 -0500
Peter Hunsberger <peter(dot)hunsberger(at)gmail(dot)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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Jaime Casanova 2009-10-28 16:13:54 Re: auto truncate/vacuum full
Previous Message Merlin Moncure 2009-10-28 15:44:46 Re: could not find array type for data type character varying[]