On Fri, Dec 15, 2017 at 6:21 PM, Laurenz Albe
wrote:
> Venkata B Nagothi wrote:
> > > > We have Timezone configured to Australia/Sydney, we can change that
> to 11 and do we need to foresee any issues ?
> > >
> > > That configuration parameter defines how the client will format
> > > timestamps t
> But for simple queries, you might get some insight if you set
> enable_seqscan to off. Then the planner will give you an index-using
> plan if it is at all possible. Then you can compare the costs. If the
> planner still gives you a sequential scan, then the index was not
> applicable for othe
Thanks Laurenz.
Greetings,
* chiru r (chir...@gmail.com) wrote:
> Please help me on below recovery scenario, if any one is using pgBackRest.
David answered your questions here:
https://www.postgresql.org/message-id/e252cb30-9707-3801-f688-75dd2cde4819%40pgmasters.net
I suggest you review/reply to that if you h
Please help me on below recovery scenario, if any one is using pgBackRest.
On Fri, Dec 15, 2017 at 4:36 PM, chiru r wrote:
> Hi All,
>
> Thanks,I am thinking about a specific recovery case.
>
> Lets assume Heavy transactional system we configured.
> It is generating WAL 2000/hr and recycling aut
On 12/16/17 04:03, Corey Taylor wrote:
> Essentially, if an index was deemed not to save cost during the input
> scan, the planner will schedule a seq scan. What I'm wondering if there
> is anything that indicates a valid index for the scan was found and
> rejected (reason doesn't necessarily matt
Stephen, Rene - Thanks!
Our experience teach us that above 20% of free space performance start to
seriously deteriorate. I'm not sure if this is related to index or table
fragmentation. We'll do our homework and we'll try to discover more.
However we have identified a process potentially caus
On 12/15/17 4:36 PM, chiru r wrote:
>
> Thanks,I am thinking about a specific recovery case.
>
> Lets assume Heavy transactional system we configured.
> It is generating WAL 2000/hr and recycling automatically in pg_wal
> directory.
>
> QA :
>
> Sunday -- 11 PM -- Full backup done.
> Monday -
This isn't meant to be a question about improving a slow query or
determining that the planner was wrong.
It seems like a simple and obvious answer, but I would love to know if
there is any documentation you can point me to read on this.
Essentially, if an index was deemed not to save cost during
