ll certainly check this out soon!
--
Victor Yegorov
> >Are there any chances to get fix for this issue released in 10.0 and,
> >perhaps, backpatched also?
>
> I'm not at my computer right now, but I recall committing something like
> my approach.
Andres, can you point me on the commit you're mentioning, please?
--
Victor Yegorov
,
we have to re-connect them to start using indexes again.
Are there any chances to get fix for this issue released in 10.0 and,
perhaps, backpatched also?
--
Victor Yegorov
2016-05-18 16:45 GMT+03:00 Robert Haas :
> No, that's what the existing FREEZE option does. This new option is
> about unnecessarily vacuuming pages that don't need it. The
> expectation is that vacuuming all-frozen pages will be a no-op.
>
VACUUM (INCLUDING ALL) ?
--
2015-12-14 5:34 GMT+02:00 Tom Lane :
> Maybe I misunderstood, but I thought what was being discussed here is
> preventing the planner from selecting an index for use in queries, while
> still requiring all table updates to maintain validity of the index.
>
The O-ther big DBMS
2013/6/1 Martijn van Oosterhout klep...@svana.org
On Sat, Jun 01, 2013 at 03:27:40PM +0430, Soroosh Sardari wrote:
Yes, I have some files which is not in pg_class.relfilenode of any table
or
index.
I want to know which table or index stored in such files.
That shouldn't happen. Are you
2013/5/17 Nikolay Samokhvalov samokhva...@gmail.com
Consider a Postgres cluster containing several DBs (for example several
projects/sites). If one wants to optimize queries on one specified site --
what should he do? His obvious need is to switch full logging for the exact
database on,
* Tom Lane [EMAIL PROTECTED] [14.07.2005 01:00]:
sk_attno?
It seems, that sk_attno holds number of scankey itself.
I have table with 3 columns (a, b, c) and index (b, c).
For both selects (only 1 where clause in both of them):
select * from tab where b = ...
and
select * from tab
Hello.
Is it possible to somehow determine index's attribute number that is target
one for given scankey?
I've checked nbtree AM code and found no evidence of such an ability. I need
that, because I'm storing each indexed value only once in a form of index
tuple, consisting of only 1 attribute.
Compiling HEAD I see the following 2 warnings:
...
make[4]: Leaving directory `/home/viy/prj/pgb/src/interfaces/ecpg/compatlib'
make -C preproc all
make[4]: Entering directory `/home/viy/prj/pgb/src/interfaces/ecpg/preproc'
make -C ../../../../src/port all
make[5]: Entering directory
Hello again.
This time I'd like to speak about in-memory bitmap to combine index scan
results. I know, this code should use minimal amount of memory, so I really
want to hear any possible pros and cons.
Below, pseudocode is given. After running it, we'll have a list of CTID
pointers, and one
* Dawid Kuroczko [EMAIL PROTECTED] [29.01.2005 21:25]:
With in-memory bitmap, the search would start with index a, all
matching rows would form the bitmap; then the second search
would go through b index, forming another bitmap. Which then
would be ANDed with previous bitmap.
Not only
12 matches
Mail list logo