| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Edmund Horner <ejrh00(at)gmail(dot)com> |
| Cc: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, tomas(dot)vondra(at)2ndquadrant(dot)com, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Tid scan improvements |
| Date: | 2018-12-20 22:21:07 |
| Message-ID: | 8469.1545344467@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Edmund Horner <ejrh00(at)gmail(dot)com> writes:
> [ tid scan patches ]
I'm having a hard time wrapping my mind around why you'd bother with
backwards TID scans. The amount of code needed versus the amount of
usefulness seems like a pretty bad cost/benefit ratio, IMO. I can
see that there might be value in knowing that a regular scan has
"ORDER BY ctid ASC" pathkeys (mainly, that it might let us mergejoin
on TID without an explicit sort). It does not, however, follow that
there's any additional value in supporting the DESC case.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2018-12-20 22:33:59 | Re: Tid scan improvements |
| Previous Message | Alvaro Herrera | 2018-12-20 22:00:22 | monitoring CREATE INDEX [CONCURRENTLY] |