On Tue, May 21, 2019 at 09:28:07PM -0700, Lev Kokotov wrote:
> Is it efficient to use Postgres as a column store by creating one table per
> column?
>
> I would query it with something like `[...] UNION SELECT value AS
> FROM WHERE value = UNION [...]` to build a row.
I think you mean JOIN not
Is it efficient to use Postgres as a column store by creating one table per
column?
I would query it with something like `[...] UNION SELECT value AS
FROM WHERE value = UNION [...]` to build a row.
I'm thinking since Postgres stores tables in continuous blocks of 16MB each
(I think that's the
On Tue, May 21, 2019 at 11:27 AM Walter Smith wrote:
> Very low. Probably less than ten over all time. I suspect the only use of the
> index is to rapidly find the processed=false rows, so the notifiable_type
> value isn’t important, really. It would probably work just as well on any
> other co
On Tue, May 21, 2019 at 8:27 PM Walter Smith wrote:
> On Tue, May 21, 2019 at 11:17 AM Peter Geoghegan wrote:
>
>> On Tue, May 21, 2019 at 11:16 AM Walter Smith
>> wrote:
>> > It occurs to me that is a somewhat unusual index -- it tracks
>> unprocessed notifications so it gets an insert and del
On Tue, May 21, 2019 at 11:17 AM Peter Geoghegan wrote:
> On Tue, May 21, 2019 at 11:16 AM Walter Smith wrote:
> > It occurs to me that is a somewhat unusual index -- it tracks
> unprocessed notifications so it gets an insert and delete for every row,
> and is normally almost empty.
>
> Is it a
On Tue, May 21, 2019 at 11:16 AM Walter Smith wrote:
> It occurs to me that is a somewhat unusual index -- it tracks unprocessed
> notifications so it gets an insert and delete for every row, and is normally
> almost empty.
Is it a very low cardinality index? In other words, is the total
number
On Tue, May 21, 2019 at 11:15 AM Peter Geoghegan wrote:
> On Tue, May 21, 2019 at 11:12 AM Walter Smith wrote
> > I did a VACUUM overnight and got the following. The thing that stands
> out to me is that one index (index_unproc_notifications_on_notifiable_type)
> took 100x longer to scan than th
On Tue, May 21, 2019 at 11:12 AM Walter Smith wrote
> I did a VACUUM overnight and got the following. The thing that stands out to
> me is that one index (index_unproc_notifications_on_notifiable_type) took
> 100x longer to scan than the others. That's not the index used in the slow
> query, th
On Mon, May 20, 2019 at 7:15 PM David Rowley
wrote:
> It would be good if you could confirm the problem is resolved after a
> vacuum. Maybe run VACUUM VERBOSE on the table and double check
> there's not some large amount of tuples that are "nonremovable".
>
As I say, the problem resolved itself
On Tue, May 21, 2019 at 04:03:52PM +, Greg Clough wrote:
My restore command copy the wals from archive dir in the primary to an
archive dir in the secondary(different from the pg_xlog in the
secondary)
I think that you're restore command puts them back into the archive, and
then uncompre
Tomas - Well, when I run the restore_command manually it works (archive
dir exists on the secondary..). Thank for the explanation on the system
catalogs..
Greg - My restore command copy the wals from archive dir in the primary to
an archive dir in the secondary(different from the pg_xlog in the
s
On Tue, May 21, 2019 at 12:01:31PM +0300, Mariel Cherkassky wrote:
Tomas :
Well, when you say it does not work, why do you think so? Does it print
some error, or what? Does it even get executed? It does not seem to be
the case, judging by the log (there's no archive_command message).
How was th
Tomas :
Well, when you say it does not work, why do you think so? Does it print
some error, or what? Does it even get executed? It does not seem to be
the case, judging by the log (there's no archive_command message).
How was the "secondary machine" created? You said you have all the WAL
since th
13 matches
Mail list logo
