Re: Pluggable Storage - Andres's take

From: Andres Freund <andres(at)anarazel(dot)de>
To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Justin Pryzby <pryzby(at)telsasoft(dot)com>, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Asim R P <apraveen(at)pivotal(dot)io>, pgsql-hackers(at)postgresql(dot)org, Ashwin Agrawal <aagrawal(at)pivotal(dot)io>, Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>
Subject: Re: Pluggable Storage - Andres's take
Date: 2019-04-23 22:52:01
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


On 2019-04-08 15:34:46 +0300, Heikki Linnakangas wrote:
> index_update_stats() calls RelationGetNumberOfBlocks(<table>). If the AM
> doesn't use normal data files, that won't work. I bumped into that with my
> toy implementation, which wouldn't need to create any data files, if it
> wasn't for this.

There are a few more of these:

1) index_update_stats(), computing pg_class.relpages

Feels like the number of both heap and index blocks should be
computed by the index build and stored in IndexInfo. That'd also get
a bit closer towards allowing indexams not going through smgr (useful
e.g. for memory only ones).

2) commands/analyze.c, computing pg_class.relpages

This should imo be moved to the tableam callback. It's currently done
a bit weirdly imo, with fdws computing relpages the callback, but
then also returning the acquirefunc. Seems like it should entirely be
computed as part of calling acquirefunc.

3) nodeTidscan, skipping over too large tids
I think this should just be moved into the AMs, there's no need to
have this in nodeTidscan.c

4) freespace.c, used for the new small-rels-have-no-fsm paths.
That's being revised currently anyway. But I'm not particularly
concerned even if it stays as is - freespace use is optional
anyway. And I can't quite see an AM that doesn't want to use
postgres' storage mechanism wanting to use freespace.c

Therefore I'm inclined not to thouch this independent of fixing the

I think none of these are critical issues for tableam, but we should fix

I'm not sure about doing so for v12 though. 1) and 3) are fairly
trivial, but 2) would involve changing the FDW interface, by changing
the AnalyzeForeignTable, AcquireSampleRowsFunc signatures. But OTOH,
we're not even in beta1.



Andres Freund

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-04-23 22:55:42 Re: Pluggable Storage - Andres's take
Previous Message David Rowley 2019-04-23 22:26:56 Re: Why does ExecComputeStoredGenerated() form a heap tuple