You can try this too:...WHERE
EXTRACT(YEAR FROM dxdate::Date) > 2000
Mauricio Fernández A.Ingeniero de
SistemasUniversidad Autónoma de Manizales (Colombia)
-Mensaje
original-De: [EMAIL PROTECTED][mailto:[EMAIL PROTECTED]]En
nombre de Bungsuputra LinanEnviado el: lunes, 27 febrero, 2
Hi Ken,
I used to have the same problem. In my computer, using date_part in WHERE
clause will always slow down the system when the table has plenty of rows.
My suggestion is try to change the query to:
... WHERE dxdate >= '2001-01-01';
I hope this helps.
Regards,
bungsu
- Original Message
bungsu,
That does make the query work a bit faster. Thanks!
On Mon, 2006-02-27 at 09:42 +0700, Bungsuputra Linan wrote:
Hi Ken,
I used to have the same problem. In my computer, using date_part in WHERE
clause will always slow down the system when the table has plenty of rows.
My suggestio
Hi, Ken,
Ken Hill wrote:
> Removing the indexes, running the update SQL, and then adding back the
> indexes worked much faster. Thank you for you help.
It might be a good idea to run VACUUM FULL between updating and reindexing.
If you want to CLUSTER on an index, it will be best to create this
On Mon, 2006-02-13 at 22:17 -0700, Michael Fuhr wrote:
[Please copy the mailing list on replies.]
On Mon, Feb 13, 2006 at 06:48:06PM -0800, Ken Hill wrote:
> On Mon, 2006-02-13 at 19:14 -0700, Michael Fuhr wrote:
> > How many rows does the condition match?
>
> csalgorithm=# SELECT count(*) F
[Please copy the mailing list on replies.]
On Mon, Feb 13, 2006 at 06:48:06PM -0800, Ken Hill wrote:
> On Mon, 2006-02-13 at 19:14 -0700, Michael Fuhr wrote:
> > How many rows does the condition match?
>
> csalgorithm=# SELECT count(*) FROM ncccr10 WHERE
> date_part('year',dxdate) > '2000';
> cou
On Mon, Feb 13, 2006 at 05:48:45PM -0800, Ken Hill wrote:
> When I try to analyze the query plan with:
>
> EXPLAIN ANALYZE
> UPDATE ncccr10
> SET key = facilityno||'-'||
> lastname||'-'||
> sex||'-'||
> ssno||'-'||
> birthdate||'-'||
> primarysit||'-'||
> dxdate
