lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Ludwig <>
Subject Re: fq vs. q
Date Mon, 15 Jun 2009 11:09:53 GMT
Ensdorf Ken schrieb:

> I ran into this very issue recently as we are using a "freshness"
> filter for our data that can be 6//12/18 months etc.  I discovered
> that even though we were only indexing with day-level granularity, we
> were specifying the query by computing a date down to the second and
> thus virutally every filter was unique.  It's amazing how something
> this simple could bring solr to it's knees on a large data set.

I want to retrieve documents (TV programs) by a particular date and
decided to convert the date to an integer, so I have:

* 20090615
* 20090616
* 20090617 etc.

I lose all date logic (timezones) for that date field, but it works for
this particular use case, as the date is merely a tag, and not a real
date I need to perform more logic on than an integer allows.

Also, an integer looks about as efficient as it gets, so I thought it
preferable to a date for this use case. YMMV.

I think if you truncate dates to incomplete dates, you effectively also
lose all the date logic. You may still apply it, but what would you take
the result to mean? You can't regain precision you've decided to drop.

The actual points in time where my TV programs start and end are
encoded as a UNIX timestamp with exactitude down to the second, also
stored as an integer, as I don't need sub-second precision.

This makes sense for my client, which is not Java, but PHP, so it uses
the C library strftime and friends, which need UNIX timestamps.

Bottom line, I think it may make perfect sense to store dates and times
in integers, depending on your use case and your client.

Michael Ludwig

View raw message