hi,
thanks for your reply. we use postgres zip, during install time of our
product, on target host this zip will be extracted. We are not creating
data directory, when service is started by default data directory will be
created.
we created/registered the service with below commands
*pg_ctl.ex
Hi Jeff,
We have encountered same problem as you (in 9.5.4), it seems that so far it
hasn’t been ported back from 9.6, but if you take this commit and apply it
to 9.5 source codes, it seems to be working
But anyway, does anybody knows plans about backporting this to 9.5 official
way?
Regar
> ~everyone wants lower data storage and wants some kind of compression.
> Can this be made to automatically retrain when analyzing (makes sense?)?
> And create a new dictionary only if it changes compared to the last one.
It's an interesting idea. However I doubt it could be automated in
one-size
> > I could align ZSON to PostgreSQL code style. I only need to run pgindent
> > and write a few comments. Do you think community would be interested in
> > adding it to /contrib/ ? I mean doesn't ZSON solve a bit too specific
> > problem for this?
>
> I find the references to pglz quite troubling
On 4 October 2016 at 16:34, Aleksander Alekseev
wrote:
> Hello, Simon.
>
> Thanks for you interest to this project!
>
>> Will you be submitting this to core?
>
> I could align ZSON to PostgreSQL code style. I only need to run pgindent
> and write a few comments. Do you think community would be int
> > I could align ZSON to PostgreSQL code style. I only need to run pgindent
> > and write a few comments. Do you think community would be interested in
> > adding it to /contrib/ ? I mean doesn't ZSON solve a bit too specific
> > problem for this?
>
> CREATE COMPRESSION DICTIONARY public.simple_d
Hello,
We're curious about the current behavior in 9.5.4, and possible future
enhancements, of BRIN indexes with respect to ordering.
In the docs, section 11.4. "Indexes and ORDER BY" (
https://www.postgresql.org/docs/9.5/static/indexes-ordering.html) is clear
that anything other than B-tree inde
Darren Lafreniere wrote:
> "In addition to simply finding the rows to be returned by a query, an index
> may be able to deliver them in a specific sorted order. This allows a
> query's ORDER BY specification to be honored without a separate sorting
> step. Of the index types currently supported by
Ahh, yes. I misread that. Thank you for the clarification.
On Wed, Oct 5, 2016 at 2:27 PM, Alvaro Herrera
wrote:
> Darren Lafreniere wrote:
>
> > "In addition to simply finding the rows to be returned by a query, an
> index
> > may be able to deliver them in a specific sorted order. This allows
On Wed, Oct 5, 2016 at 3:55 PM, otheus uibk wrote:
>
>
> On Tue, Oct 4, 2016 at 10:49 PM, Magnus Hagander
> wrote:
>
>>
>>
>> On Tue, Oct 4, 2016 at 10:42 PM, otheus uibk
>> wrote:
>>
>>> After a 3 to 4 minute delay, pg_basebackup started doing it's thing and
>>> finished within a few minutes.
Hi again,
On Mon, 2016-10-03 at 00:18 +, Edson Richter wrote:
> It is not working, I get the following error:
>
> [root@backup1 yum.repos.d]# LANG=C yum install pgadmin4 pgadmin4-web
> Loaded plugins: ulninfo
> epel/x86_64/metalink | 2.6 kB 00:00:00
> ol7_UEKR3 | 1.2 kB 00:00:00
> ol7_late
Alvaro Herrera writes:
> Darren Lafreniere wrote:
>> We found a pgsql-hackers thread from about a year ago about optimizing
>> ORDER BY for BRIN indexes. Tom Lane suggested that he was working on it:
>> https://www.postgresql.org/message-id/11881.1443393360%40sss.pgh.pa.us
> Tom said he was worki
Tom Lane wrote:
> > Gavin Wahl wrote:
> >> It seems trivial to accelerate a MAX or MIN query with a BRIN index. You
> >> just find the page range with the largest/smallest value, and then only
> >> scan that one. Would that be hard to implement? I'm interested in
> working
> >> on it if someone c
Darren,
* Darren Lafreniere (dlafreni...@onezero.com) wrote:
> Tom Lane wrote:
> > > Gavin Wahl wrote:
> > >> It seems trivial to accelerate a MAX or MIN query with a BRIN index. You
> > >> just find the page range with the largest/smallest value, and then only
> > >> scan that one. Would that be
Devrim Gündüz escreveu
> Hi again,
>
> On Mon, 2016-10-03 at 00:18 +, Edson Richter wrote:
> > It is not working, I get the following error:
> >
> > [root@backup1 yum.repos.d]# LANG=C yum install pgadmin4 pgadmin4-web
> > Loaded plugins: ulninfo
> > epel/x86_64/metalink | 2.6 kB 00:
Stephen Frost wrote:
> For at least some of the common BRIN use-cases, where the rows are
> inserted in-order and never/very-rarely modified or deleted, this
> approach would work very well.
>
Thanks Stephen, this is exactly our use case.
hi Thomas,
thanks for your reply. small correction for my previous reply, we use
postgresql zip and bundle with our products installer, during install time
of our product, on target host this zip will be extracted. Data directory
is under pgsql along with bin and other directories.
we created
17 matches
Mail list logo