Re: how to vacuum thru psycopg

Tim Roberts <[email protected]>
Newsgroups gmane.comp.python.db.psycopg.devel
Organization Providenza & Boekelheide, Inc.
Message-ID <[email protected]>
Al Niessner wrote:
> You all are probably going to hate me for this, but I need to give you a
> picture to help clarify what I am talking about.

That's a very revealing graph.  I know you came in hoping to solve a
very focused problem, and I hope you will not be upset if I veer off to
explore your database layout a bit.  I'm still not 100% clear on your
schema, but I have a suspicion that your trouble is coming from the schema.

> If you do not know, EXIF data is a set of name-value pairs. For brevity,
> EXIF uses a 16 bit int for its name and then some variable length number
> of bytes for the value. Of the images being scanned, it is normal for
> the EXIF data to be 40 or 44 pairs in size, but there are some that are
> zero. Of these 44 or so pairs, only about 10 of them change. So, what I
> do is scan the table to see if the pair exists. If it does, then I leave
> it be and just point the image at it (another table with 2 foreign keys
> relating the picture to the pair). So, pair table should never really
> have that many entries. The table that relates the picture to the pair
> is huge (number of pictures * 44) but it is just a primary key and two
> foreign keys, which should be very fast.
>   

OK, so you have a table with EXIF key, EXIF value, and a unique ID. 
Then, you have another table with picture number, EXIF key, and the
unique ID from the EXIF table.  Is that right?

How are you determining whether the pair exists?  Are you actually doing
a SELECT for each pair?  That is, you're doing 44 SELECTs for every
picture before doing the INSERT?  Since each one of those is a server
round trip, doesn't it seem obvious that this is where your performance
is being eaten up?

You're doing these extra lookups just to save disk space, right?  I
would assert that this is a false optimization.  If it were me, I'd just
have a table with picture number, EXIF key, and EXIF value, and store
each image's keys in there unconditionally.  You'll have the same number
of records as in your relation table, but the records will be a bit
larger.  You're talking about, what, maybe 400 bytes of EXIF data per
image?  That's well under 10 megabytes total.

I think you are making a lot of extra work for yourself with no tangible
benefit.

> So, I have this huge time sink that is strictly database related and my
> best suggestion so far was to vacuum once in a while. I am welcome to
> entertain other suggestions.
>   

Never let it be said that I hesitated in giving unwanted advice.

-- 
Tim Roberts, [email protected]
Providenza & Boekelheide, Inc.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.