| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Arturo Perez <aperez(at)hayesinc(dot)com> |
| Cc: | pgsql-general(at)postgresql(dot)org |
| Subject: | Re: Adding TEXT columns tanks performance? |
| Date: | 2007-02-10 17:34:20 |
| Message-ID: | 18694.1171128860@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Arturo Perez <aperez(at)hayesinc(dot)com> writes:
> Saturday I changed a table to add a varchar(24) and a TEXT column.
You didn't actually say which of these tables you changed?
> I'm not very good at reading these but it looks like sort memory might
> be too low?
The runtime seems to be entirely in the index scan on user_tracking.
I'm surprised it doesn't do something to avoid a full-table indexscan
--- in this case, hashing with extended_user as the inner relation would
seem like the obvious thing. Is user_id a hashable datatype?
It's possible that adding the columns would have affected the plan by
making it look like a sort or hash would take too much memory, but if
that were it then your hand increase in work_mem should have fixed it.
Tis odd. I don't suppose you know what plan was used before?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Webb Sprague | 2007-02-10 18:43:11 | MOVE cursor in plpgsql? |
| Previous Message | Tom Lane | 2007-02-10 17:25:42 | Re: Trouble w/plperl sproc on red hat 9 |