ENH: Add VOParquet support for TAP queries

[stvoutsin]

I am wondering if it would be worth adding support for VOParquet (https://www.ivoa.net/documents/Notes/VOParquet/20250116/NOTE-voparquet-1.0-20250116.html)?

This is supported as far as I can see in astropy, see:

job = AsyncTAPJob.create(
    service.baseurl, query,
    RESPONSEFORMAT="application/vnd.apache.parquet",
    session=session
)
job = job.run().wait()
response = session.get(job.result_uri, stream=True)
table = Table.read(io.BytesIO(response.content),
                   format="parquet.votable")

At Rubin we do currently support VOParquet output and are generally eager to start advertising that option more because of the noticeable performance improvements it gives us, so it would be nice if this was possible through PyVO.

If folks think this is worth adding I'm happy to work on this if no one else already was planning to do so.

[bsipocz]

At Rubin we do currently support VOParquet output and are generally eager to start advertising that option more because of the noticeable performance improvements it gives us, so it would be nice if this was possible through PyVO.

What aspects would you think should live in pyvo as opposed in upstream? As I see this is more analogous to the xml parsing we do in astropy, so ideally all of the components should live there.

(should we chat about it 1)here, 2) on slack or 3) during the interop?)

[stvoutsin]

I will be attending the Interop, so happy to chat about it there.
A preview of what I'm thinking is that indeed the parsing is handled by Astropy, and PyVO handles the transport layer:

• Detecting the content-type of the response and routing to the right method
• If content type is Parquet, route to Table.read(..., format="parquet.votable") instead of votableparse.
• Changing run_sync/run_async to allow setting the right responseformat

[andamian]

It is a sensible thing to do IMO even if VOParquet is not a REC since the actual implementation is upstream.