| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Rui Hai Jiang <ruihaijiang(at)msn(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Is it possible and worthy to optimize scanRTEForColumn()? |
| Date: | 2017-12-08 19:35:11 |
| Message-ID: | 20171208193511.2xn2tbwetxsvey23@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2017-12-08 10:05:17 -0500, Tom Lane wrote:
> I'm not particularly concerned about it --- I've not seen profiles
> suggesting that that function is a big time sink. Tables with very
> many columns tend to be inefficient for lots of reasons, and I rather
> doubt that this particular place is the first thing to hit if you
> want to make that better.
FWIW, I've definitely seen scanRTEForColumn() show up in profiles. In
some of those cases the issue could be worked around by mostly using
prepared statements. But it definitely can be painful, not that
surprising given the the complexity is essentially
O(#available-columns * #looked-up-columns).
However I don't think a microoptimization, even if it were correct, as
breaking earlier out of the loop would help meaningfully. We'd need a
different datastructure.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2017-12-08 19:41:14 | Re: Is it possible and worthy to optimize scanRTEForColumn()? |
| Previous Message | Robins Tharakan | 2017-12-08 19:32:41 | Typo in recent commit |