clusters - Search results
Mailing lists >> pgsql-hackers >> Thread
2022-06-16 16:48:34 | Re: Modest proposal to extend TableAM API for controlling cluster commands (Mark Dilger)
cluster or vacuum full, without the overhead of needlessly copying itself, and without causing argumentless
Mailing lists >> pgsql-hackers >> Thread
2022-06-16 16:10:06 | Re: Modest proposal to extend TableAM API for controlling cluster commands (Mark Dilger)
Yes, and I think I'm perfectly correct in asking for that. If the standard
Mailing lists >> pgsql-hackers >> Thread
2022-06-16 07:28:48 | Re: Modest proposal to extend TableAM API for controlling cluster commands (David G. Johnston)
On Wed, Jun 15, 2022 at 11:23 PM Mark Dilger
Mailing lists >> pgsql-hackers >> Thread
2022-06-16 07:27:59 | Re: Modest proposal to extend TableAM API for controlling cluster commands (Andres Freund)
Hi, On 2022-06-15 22:23:36 -0700, Mark Dilger wrote: The tradeoff is
Mailing lists >> pgsql-hackers >> Thread
2022-06-16 06:23:09 | Re: Modest proposal to extend TableAM API for controlling cluster commands (Mark Dilger)
Ok. I submit that's the only sane thing to do if the table AM
Mailing lists >> pgsql-hackers >> Thread
2022-06-16 05:23:36 | Re: Modest proposal to extend TableAM API for controlling cluster commands (Mark Dilger)
CLUSTER supposed to do? Seems like the answer is "diddly squat", and yet you seem
Mailing lists >> pgsql-hackers >> Thread
2022-06-16 03:50:31 | Re: Modest proposal to extend TableAM API for controlling cluster commands (David G. Johnston)
CLUSTER there should be an error: which makes the implicit CLUSTER command a non-factor
Mailing lists >> pgsql-hackers >> Thread
2022-06-16 03:18:50 | Re: Modest proposal to extend TableAM API for controlling cluster commands (Andres Freund)
cluster optional. I still think it's a terrible idea to silently ignore tables in CLUSTER
Mailing lists >> pgsql-hackers >> Thread
2022-06-16 03:10:30 | Re: Modest proposal to extend TableAM API for controlling cluster commands (Mark Dilger)
cluster code will replace the old table with the new one. I'm left no choices
Mailing lists >> pgsql-hackers >> Thread
2022-06-16 02:30:04 | Re: Modest proposal to extend TableAM API for controlling cluster commands (Andres Freund)
Hi, On 2022-06-15 19:21:42 -0700, Mark Dilger wrote: Hardly a synonym
Mailing lists >> pgsql-hackers >> Thread
2022-06-16 02:24:59 | Re: Modest proposal to extend TableAM API for controlling cluster commands (Mark Dilger)
I should admit that this is a bit hack-ish, but TAM authors haven't
Mailing lists >> pgsql-hackers >> Thread
2022-06-16 02:21:42 | Re: Modest proposal to extend TableAM API for controlling cluster commands (Mark Dilger)
cluster will be set. Heap-AM plays along and sorts or not based on that
Mailing lists >> pgsql-hackers >> Thread
2022-06-16 02:14:21 | Re: Modest proposal to extend TableAM API for controlling cluster commands (Andres Freund)
CLUSTER. While a good bit of the implementation is shared, VACUUM FULL doesn't order
Mailing lists >> pgsql-hackers >> Thread
2022-06-16 02:07:50 | Re: Modest proposal to extend TableAM API for controlling cluster commands (Mark Dilger)
CLUSTER" doesn't depend on whether the target is pre-clustered, and both will run against
Mailing lists >> pgsql-hackers >> Thread
2022-06-16 01:55:04 | Re: Modest proposal to extend TableAM API for controlling cluster commands (Andres Freund)
clustered tables get clustered in an argumentless CLUSTER. What am I missing? Greetings, Andres Freund