Steven Schlansker-3 wrote
> The code may get changed multiple times in the same day, if I am
> busy hacking on it.
On the production table???
The other thought-line is just use a (primary key, version) index and make
use LIMIT / OFFSET with an ORDER BY on the PK and the filter on version
AFTER th
On Jun 18, 2013, at 2:29 PM, Jeff Janes wrote:
> On Tue, Jun 18, 2013 at 12:17 PM, Steven Schlansker
> wrote:
> Hi everyone,
>
> I assume this is not easy with standard PG but I wanted to double check.
>
> I have a column that has a very uneven distribution of values. ~95% of the
> values
On Tue, Jun 18, 2013 at 12:17 PM, Steven Schlansker wrote:
> Hi everyone,
>
> I assume this is not easy with standard PG but I wanted to double check.
>
> I have a column that has a very uneven distribution of values. ~95% of
> the values will be the same, with some long tail of another few dozen
On Jun 18, 2013, at 1:49 PM, David Johnston wrote:
> Steven Schlansker-3 wrote
>> At some point, the code changes, and CURRENT_VERSION gets incremented.
>> Rows then slowly (over a period of days / weeks) get "upgraded" to the new
>> current version, in batches of thousands.
>>
>> This is what
Steven Schlansker-3 wrote
> At some point, the code changes, and CURRENT_VERSION gets incremented.
> Rows then slowly (over a period of days / weeks) get "upgraded" to the new
> current version, in batches of thousands.
>
> This is what I mean by a very slowly changing mostly-constant value.
Thi
Steven Schlansker-3 wrote
> 1) The common value is not known at schema definition time, and may change
> (very slowly) over time.
>
> 2) JDBC uses prepared statements for everything, and the value to be
> selected is not known at statement prepare time, so any partial indices
> are ignored (this i
On Jun 18, 2013, at 12:23 PM, John R Pierce wrote:
> On 6/18/2013 12:17 PM, Steven Schlansker wrote:
>> 1) The common value is not known at schema definition time, and may change
>> (very slowly) over time.
>
> how could a value thats constant in 95% of the rows change, unless you added
> 20
On 6/18/2013 12:17 PM, Steven Schlansker wrote:
1) The common value is not known at schema definition time, and may change
(very slowly) over time.
how could a value thats constant in 95% of the rows change, unless you
added 20 times more rows with a new value (and for a big portion of the
t
