Tom Lane wrote:
Why are you worrying? The old method surely didn't get indexed either.
Continuous improvement?
Since there already IS an index available, I figure I might as well use
it, especially since this DB had real performance issues. The table
itself is medium sized in our world, at
Bryce Nesbitt writes:
> I've got a legacy app that does 8.3 incompatible date searches like so:
> explain select count(*) from contexts where publication_date like '2006%';
> explain select count(*) from contexts where publication_date like
> '2006-09%';
> I've got my choice of refactoring, but a
Scott Marlowe escribió:
> On Thu, Dec 18, 2008 at 10:46 PM, Bryce Nesbitt wrote:
> > I've got a legacy app that does 8.3 incompatible date searches like so:
> > explain select count(*) from contexts where publication_date like '2006%';
> > explain select count(*) from contexts where publication_da
On Thu, Dec 18, 2008 at 10:46 PM, Bryce Nesbitt wrote:
> I've got a legacy app that does 8.3 incompatible date searches like so:
> explain select count(*) from contexts where publication_date like '2006%';
> explain select count(*) from contexts where publication_date like
> '2006-09%';
>
> I've g
I've got a legacy app that does 8.3 incompatible date searches like so:
explain select count(*) from contexts where publication_date like '2006%';
explain select count(*) from contexts where publication_date like
'2006-09%';
I've got my choice of refactoring, but all these share the same
sequentia